Rendering graphical scenes

ABSTRACT

A device may receive information that specifies a graphical scene. The graphical scene may include a coordinate axis. Data, to be plotted in the graphical scene, may be plotted with regard to the coordinate axis. The device may generate a structured plurality of objects. One or more objects, of the structured plurality of objects, may store properties that define the graphical scene. A particular object, of the one or more objects, may store properties that define one or more elements of the coordinate axis. The device may receive information identifying a modification to an element of the coordinate axis, of the one or more elements of the coordinate axis. The device may modify a property of the properties that define the one or more elements of the coordinate axis, based on the instruction, to implement the modification specified by the instruction.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A-1C are diagrams of an overview of example implementations,described herein;

FIG. 2 is a diagram of an example environment in which systems and/ormethods, described herein, may be implemented;

FIG. 3 is a diagram of example components of one or more devices of FIG.2;

FIGS. 4A-4C are diagrams of an example implementation of generating anobject tree and rendering a graphical scene based on applicationprogramming interface instructions;

FIGS. 5A-5E are diagrams of an example implementation of modifying anobject tree and rendering a graphical scene based on applicationprogramming interface instructions;

FIG. 6 is a flow chart of an example process for generating a graphicalscene, including a common axis and at least two other axes, based onapplication programming interface instructions;

FIG. 7 is a flow chart of an example process for modifying a graphicalscene, including a common axis and at least two other axes, based onapplication programming interface instructions;

FIGS. 8A and 8B are diagrams of an example implementation of generatingan object tree and rendering a graphical scene, including specified axislimits, based on application programming interface instructions;

FIGS. 9A and 9B are diagrams of an example implementation of generatingan object tree and rendering a graphical scene, including multiple,concurrently plotted data sets, based on application programminginterface instructions;

FIG. 10 is a diagram of an example implementation of generating anobject tree and rendering a graphical scene, including a specifiedpattern and a specified layer, based on application programminginterface instructions;

FIGS. 11A-11F are diagrams of an example implementation of generatingand modifying an object tree, and rendering graphical scenes, includingpolar plots, based on application programming interface instructions;

FIG. 12 is a diagram of an example implementation of rendering agraphical scene, including tick mark labels in a specified numericalformat, based on application programming interface instructions;

FIGS. 13A and 13B are diagrams of an example implementation ofgenerating an object tree and rendering a graphical scene, includingspecified line widths, based on application programming interfaceinstructions;

FIG. 14 is a diagram of an example implementation of rendering agraphical scene, including a specified range of a data set, based onapplication programming interface instructions;

FIG. 15 is a diagram of an example implementation of rendering agraphical scene, including a specified location of an r-axis, based onapplication programming interface instructions;

FIG. 16 is a flow chart of an example process for generating a graphicalscene, related to a polar coordinate system, based on an object tree;

FIGS. 17A and 17B are diagrams of an example implementation ofgenerating and modifying an object tree including a ruler object, andrendering graphical scenes, based on application programming interfaceinstructions;

FIGS. 18A and 18B are diagrams of an example implementation ofgenerating and modifying an object tree including a ruler object, andrendering graphical scenes, based on application programming interfaceinstructions;

FIG. 19 is a diagram of an example implementation of modifying agraphical scene based on application programming interface instructions;

FIGS. 20A-20D are diagrams of an example implementation of generatingand modifying axes of graphical scenes based on application programminginterface instructions and based on a generated object tree; and

FIG. 21 is a flow chart of an example process for generating and/ormodifying an object of an object tree based on a user input.

DETAILED DESCRIPTION

The following detailed description of example implementations refers tothe accompanying drawings. The same reference numbers in differentdrawings may identify the same or similar elements.

A device may receive an application programming interface (API)instruction (e.g., from a user, such as a computer programmer, from anapplication, from a device, etc.) based on an API. The API instructionmay include, for example, a command in a programming language (e.g.,MATLAB, C, etc.). For example, the API instruction may include“plot(y),” to cause the device to generate a graphical scene including aplot of values of “y,” or a similar command. Upon receiving the APIinstruction, the device may render and/or provide a graphical scene. Torender, or modify, elements of the graphical scene, the device maycreate objects in an object-oriented programming environment. In someimplementations, an object stores properties relating to the graphicalscene. In some cases, an object may perform operations with respect tothe properties stored by the object and/or with respect to propertiesstored by other objects.

In some cases, the created objects may share a hierarchical relationship(e.g., between a first object and a set of second objects that, whenmodified, may necessitate a modification to the first object to properlyrender the graphical scene). The hierarchical relationship between thefirst object and the set of second objects may be referred to herein asan object tree. The device (e.g., a graphics system associated with thedevice) may render the graphical scene based on properties stored bysome or all of the first object and/or the set of second objects, suchas axis labels, axis position indicators, axis tick mark spacingindicators, values to be displayed in the graphical scene, or the like.The device may generate a graphical rendering tree based on the objecttree, which may improve efficiency of rendering the graphical scene. Thegraphical rendering tree may be configured to obtain a desiredperformance (e.g., desired memory allocation and usage, rendering usingless than a threshold quantity of processor cycles, rendering in lessthan a threshold amount of time, etc.) from a specialized processor forrendering the graphical scene, such as a graphics processing unit.

An object tree may include a dataspace object. In some implementations,a dataspace object includes properties that define operations to performwith respect to objects of the object tree or another object tree inorder to generate or modify the graphical scene based on an input. Forexample, the dataspace object may convert properties of an object from afirst coordinate system (e.g., a Cartesian coordinate system) to asecond coordinate system (e.g., a polar coordinate system). As anotherexample, the dataspace object may determine an upper limit and/or alower limit of a coordinate axis included in the graphical scene basedon the properties. As yet another example, the dataspace object maymodify the properties to change relative locations, spacing, style,quantity, size, etc. of elements of the graphical scene, or may performother operations.

In some implementations, an object may store properties related torendering the graphical scene, or may store information identifying alocation of the properties (e.g., by identifying a path to anotherobject that stores the properties). The object may manage creation ofthe dataspace objects and/or objects of the object tree (e.g., bydetermining which objects need to be created based on an input, bycreating appropriate objects for an input, by determining values ofproperties to assign to the created objects, etc.).

In some cases, a particular object tree may be adapted to performoperations to render a particular type of graphical scene. As a firstcase, consider a graphical scene that includes a plot, and assume thatthe plot includes a common horizontal axis and two vertical axesincluding a left vertical axis and a right vertical axis. Data that isplotted on the plot may be plotted in relation to the common axis andthe left vertical axis, or in relation to the common axis and the rightvertical axis.

In this first case, a first set of objects may store properties (e.g.,axis labels, axis position indicators, axis tick mark spacingindicators, values to be displayed with regard to the left verticalaxis) related to the left vertical axis. A second set of objects maystore properties (e.g., axis labels, axis position indicators, axis tickmark spacing indicators, values to be displayed with regard to the leftvertical axis) related to the right vertical axis.

To properly render the graphical scene, the object tree may need to becapable of performing operations with regard to both the first set ofobjects and the second set of objects. For example, if an APIinstruction indicates that data presented with regard to the leftvertical axis is to be magnified, the dataspace object may modify anupper limit and/or a lower limit of the common axis and the leftvertical axis, and the graphical scene may be rendered based on themodified limits. However, by modifying the upper limit and/or the lowerlimit of the common axis and the left vertical axis, the dataspaceobject may cause data that is plotted in relation to the common axis andthe right vertical axis to be plotted incorrectly and/or in anundesirable manner. Implementations described herein describe an objecttree including a dataspace object for the left vertical axis, andanother dataspace object for the right vertical axis. The dataspaces forthe left vertical axis and the right vertical axis may both be capableof performing transformations based on properties of objects relating tothe common, horizontal axis. In this way, implementations describedherein permit more intuitive and efficient generation and modificationof graphical scenes including three or more axes, which conservesprocessor resources otherwise used for processor-intensive workarounds,and which saves user time by allowing users to quickly gain andcommunicate insights about graphed information.

As a second case, consider a graphical scene that depicts a plot. Datamay be plotted in relation to one or more axes of the plot, and the oneor more axes may be generated based on objects of an object tree. A usermay want to customize elements of the graphical scene related to the oneor more axes. For example, the user may want to specify a particularformat, content, and/or positioning of axis labels, may want to change aspacing, format, labeling, and/or style of markings (e.g., tick marks)of the axis, may want to reposition the axis, may want to specify aparticular precision of numbers displayed in association with the axis,or the like. Implementations described herein describe an object, of theobject tree, that stores properties that permit customization of theabove elements related to the one or more axes.

As a third case, consider a graphical scene that includes a polar plot.In some cases, some objects, of an object tree, may be inefficient atand/or incapable of storing and/or processing data in a polar coordinatesystem. For example, the object tree may be generated based on aCartesian coordinate system. To plot data in a non-Cartesian coordinatesystem, the object tree may perform operations to approximate thenon-Cartesian coordinate system plot. For example, the object tree mayconvert data in a polar coordinate system to the Cartesian coordinatesystem, and may draw polar axes using an object adapted for drawingCartesian axes.

However, by performing operations based on objects adapted for theCartesian coordinate system, the object tree may reduce customizabilityof the polar plot (e.g., by changing a color of an element, plotting asub-set of data included in the object tree, customizing tick marks,labels, line types, scaling, etc., concurrently plotting multipledatasets in one polar plot, etc.). For example, API instructions that auser may expect to work for a polar plot may not function properly basedon the mismatch between the data in the polar coordinate system and theobject tree in the Cartesian coordinate system. Implementationsdescribed herein may enable the device to generate a polar object treeincluding properties adapted for the polar coordinate system. In someimplementations, the device may generate and/or modify the polar objecttree based on API instructions that are similar to API instructions forcorresponding modifications in a Cartesian coordinate system. Forexample, the device may generate and/or modify the polar object treeusing a base class associated with the Cartesian coordinate system.

FIGS. 1A-1C are diagrams of an overview of an example implementation100, described herein. For the purpose of FIGS. 1A-1C, assume that adevice is capable of performing various operations related to agraphical scene, based on receiving an API instruction. As shown in FIG.1A, device 102 may receive API instructions 104-110 relating togenerating a Cartesian plot 112. In particular, one API instruction 104is plot(y1, ‘- -’), for generating a plot of a dataset y1 with a dashedline.). Another API instruction 106 is hold on, for plotting a seconddataset y2. In some implementations, the API instruction 106 may includehold(‘on’), or the like. The two data sets 114 and 116 are plotted onthe same plot 112 without removing the plot of the first dataset (e.g.,“hold on”). As further shown, device 102 receives an API instruction 108to plot a second dataset (e.g., “plot(y2, ‘:’),” which may generate aplot of a dataset y2 with a dotted line). As shown, device 102 receivesan API instruction 110 to specify limits of an x-axis (e.g.,“ax.XLim(0,4),” which may set an upper limit and a lower limit of thex-axis 118 to 0 and 4, respectively).

As shown, in some cases, in order to cause device 102 to generate apolar plot 130, a user may add a string “polar” to the beginning of APIinstructions 104 and 108. That is, where “plot(y)” generates plot 112based on a dataset of y, “polarplot(r)” generates a polar plot based ona dataset of r. Device 102 may receive an API instruction 122 to plot afirst dataset r1 on plot 130 (e.g., “polarplot(r1, ‘- -’),” whichgenerates a plot of a dataset r1 with a dashed line 132). As shown inthe corresponding plot 130, device 102 may plot the dataset r1 with thedashed line. As shown, device 102 may receive an API instruction 124 toplot a dataset without removing a plot of the first dataset (e.g., “holdon”).

As shown, device 102 may receive an API instruction 126 to plot a seconddataset (e.g., “polarplot(r2, ‘:’),” which generates a plot of a datasetr2 with a dotted line). As shown in plot 130, device 102 plots r2 withthe dotted line, without removing the plotted dataset r1. As shown,device 102 may receive an API instruction 128 to specify limits of atheta-axis (e.g., “ax.ThetaLim(0,4*pi),” which may set an upper limitand a lower limit of the theta-axis to 0 and 4*pi, respectively). Asshown in plot 130, device 102 sets the upper and lower limits of thetheta-axis accordingly. In this way, device 102 generates a polar plot130 based on API instructions that are logically similar to APIinstructions to generate a Cartesian plot 112, which improves usabilityand conserves processor resources that may otherwise be used toimplement resource-intensive workarounds.

As shown in FIG. 1B, device 102 may receive API instructions 138-148related to generating a graphical scene. The graphical scene may includea plot 152 that includes one common axis and two other axes. As shown,device 102 receives an API instruction 138 to specify a left axis, ofthe two other axes (e.g., “yyaxis left”), and generates plot 152 with anx-axis and a left y-axis. As shown, device 102 receives an APIinstruction 140 to plot a first set of data 154 in relation to thecommon x-axis and the left y-axis (e.g., “plot(y1)”). As shown, device102 receives an API instruction 142 to set a scale of the active axis(e.g., the left y-axis, based on the API instruction 138 of “yyaxisleft”) to a linear scale, and sets the scale of the left y-axisaccordingly.

As shown, device 102 receives an API instruction 144 to specify a rightaxis, of the two other axes (e.g., as “yyaxis right”), and generates aright y-axis on the plot 152. As shown, device 102 receives an APIinstruction 146 to plot a second set of data 156 in relation to thecommon x-axis and the right y-axis (e.g., “plot(y2)”). As shown, device102 receives an API instruction 148 to set a scale of the active axis(e.g., the right y-axis, based on the API instruction 144 of “yyaxisright”) to a logarithmic scale, and sets the scale of the right y-axisaccordingly. In this way, device 102 efficiently plots multiple datasetsin relation to a common axis. Device 102 customizes one or more otheraxes based on API instructions, and performs operations to improveaccuracy and/or versatility of the common axis and the one or more otheraxes, as described in more detail below.

As shown in FIG. 1C, device 102 receives API instructions 158-166related to customizing an x-axis and a y-axis of a plot 168. As shown,device 102 receives an API instruction 158 to plot a set of data (e.g.,“plot(y)”), and plots the set of data accordingly, as shown by referencenumber 172. As shown, device 102 receives API instructions 160 todisplay axes of the plot 168 as crossing at the origin of the plot(e.g., “YAxisLocation=‘origin’) and XAxisLocation=‘origin’”), andformats the x-axis and the y-axis accordingly. As shown, device 102receives an API instruction 162 to specify an exponent for labels of they-axis 170 (e.g., “ax.YAxis.exponent=9”), and an API instruction 164related to formatting tick mark labels of the y-axis (e.g.,“ax.YAxis.TickLabelFormat=‘%.2f’,” which causes device 102 to generatetick mark labels with two digits after the decimal and no trailingzero). As shown, device 102 receives an API instruction 166 toautomatically determine minor tick mark values for the x-axis (e.g.,“ax.XAxis.MinorTickValuesMode=‘auto’”), and modifies the x-axis of theplot 168 accordingly.

In this way, device 102 renders a graphical scene that includes a plotbased on a variety of API instructions. Device 102 may render thegraphical scene based on an object tree that may be adapted to improveperformance of device 102 during rendering and/or modification of thegraphical scenes, as described in more detail elsewhere herein. Theobject tree may be configured to modify particular properties of objectsof the object tree based on the variety of API instructions, which maypermit customization of the graphical scenes and/or reduce processorresource usage related to customizing the graphical scenes using costlyworkarounds.

FIG. 2 is a diagram of an example environment 200 in which systemsand/or methods, described herein, may be implemented. As shown in FIG.2, environment 200 may include a client device 210, which may include atechnical computing environment (TCE) 220. Furthermore, environment 200may include a server device 230, which may include TCE 220, and anetwork 240. Devices of environment 200 may interconnect via wiredconnections, wireless connections, or a combination of wired andwireless connections.

Client device 210 may include one or more devices capable of receiving,generating, storing, processing, and/or providing program code, agraphical scene, and/or information associated with the program codeand/or the graphical scene. For example, client device 210 may include acomputing device, such as a desktop computer, a laptop computer, atablet computer, a mobile phone (e.g., a smart phone, a radiotelephone,etc.), or a similar device. Client device 210 may generate and/or modifya graphical scene. In some implementations, client device 210 mayreceive input (e.g., program code, an application programming interface(API) instruction, user input including program code and/or an APIinstruction, a mouse click, a mouse drag, a sensor input, an externaldevice input, etc.), and may render and/or modify the graphical scenebased on the input. In some implementations, client device 210 maygenerate and/or modify an object tree and/or a graphical rendering treebased on the input. In some implementations, client device 210 mayreceive information from and/or transmit information to server device230.

Client device 210 may host TCE 220. TCE 220 may include anyhardware-based component or a combination of hardware and software-basedcomponents that provides a computing environment that allows tasks to beperformed (e.g., by users) related to disciplines, such as, but notlimited to, mathematics, science, engineering, medicine, and business.TCE 220 may include a text-based environment (e.g., MATLAB® software byThe MathWorks, Inc.), a graphically-based environment (e.g., Simulink®software, Stateflow® software, SimEvents® software, etc., by TheMathWorks, Inc.; VisSim by Visual Solutions; LabView® by NationalInstruments; Agilent VEE by Agilent Technologies; Advanced Design System(ADS) by Agilent Technologies; Agilent Ptolemy by Agilent Technologies;etc.), or another type of environment, such as a hybrid environment thatmay include, for example, a text-based environment and agraphically-based environment.

TCE 220 may include, for example, a user interface that provides a codeeditor that permits a user to input and/or edit program code, such asAPI instructions. Additionally, or alternatively, TCE 220 may include auser interface that includes a command line that permits a user to inputand/or edit program code (e.g., API instructions). Based on inputtedprogram code, TCE 220 may cause a device (e.g., client device 210,server device 230, etc.) to modify an object tree, a graphical renderingtree, and/or a graphical scene. In some implementations, TCE 220 mayprovide, for display, a graphical scene that may be rendered based on anobject tree and/or a graphical rendering tree.

Server device 230 may include one or more devices capable of receiving,generating, storing, processing, and/or providing program code, agraphical scene, and/or information associated with the program codeand/or the graphical scene. For example, server device 230 may include acomputing device, such as a server, a desktop computer, a laptopcomputer, a tablet computer, or a similar device. Server device 230 maygenerate and/or modify a graphical scene. In some implementations,server device 230 may receive input (e.g., program code, an applicationprogramming interface (API) command, user input including program codeand/or an API command, etc.), and may generate and/or modify thegraphical scene based on the input. In some implementations, serverdevice 230 may generate and/or modify an object tree and/or a graphicalrendering tree based on the input.

In some implementations, server device 230 may host TCE 220. In someimplementations, client device 210 may be used to access one or moreTCEs 220 running on one or more server devices 230. For example,multiple server devices 230 may be used to execute program code (e.g.,serially or in parallel), and may provide respective results ofexecuting the program code to client device 210.

In some implementations, client device 210 and server device 230 may beowned by different entities. For example, an end user may own clientdevice 210, and a third party may own server device 230. In someimplementations, server device 230 may include a device operating in acloud computing environment. In this way, front-end applications (e.g.,a user interface) may be separated from back-end applications (e.g.,program code execution). Additionally, or alternatively, server device230 may perform one, more, or all operations described elsewhere hereinas being performed by client device 210.

Network 240 may include one or more wired and/or wireless networks. Forexample, network 240 may include a cellular network, a public landmobile network (PLMN), a local area network (LAN), a wide area network(WAN), a metropolitan area network (MAN), a telephone network (e.g., thePublic Switched Telephone Network (PSTN)), an ad hoc network, anintranet, the Internet, a fiber optic-based network, a private network,a cloud computing network, and/or a combination of these or other typesof networks.

The number and arrangement of devices and networks shown in FIG. 2 areprovided as an example. In practice, there may be additional devicesand/or networks, fewer devices and/or networks, different devices and/ornetworks, or differently arranged devices and/or networks than thoseshown in FIG. 2. Furthermore, two or more devices shown in FIG. 2 may beimplemented within a single device, or a single device shown in FIG. 2may be implemented as multiple, distributed devices. Additionally, oralternatively, a set of devices (e.g., one or more devices) ofenvironment 200 may perform one or more functions described as beingperformed by another set of devices of environment 200.

FIG. 3 is a diagram of example components of a device 300. Device 300may correspond to client device 210 and/or server device 230. In someimplementations, client device 210 and/or server device 230 may includeone or more devices 300 and/or one or more components of device 300. Asshown in FIG. 3, device 300 may include a bus 310, a processor 320, amemory 330, a storage component 340, an input component 350, an outputcomponent 360, and a communication interface 370.

Bus 310 may include a component that permits communication among thecomponents of device 300. Processor 320 is implemented in hardware,firmware, or a combination of hardware and software. Processor 320 mayinclude a processor (e.g., a central processing unit (CPU), a graphicsprocessing unit (GPU), an accelerated processing unit (APU), etc.), amicroprocessor, and/or any processing component (e.g., afield-programmable gate array (FPGA), an application-specific integratedcircuit (ASIC), etc.) that can be programmed to perform a function.Memory 330 may include a random access memory (RAM), a read only memory(ROM), and/or another type of dynamic or static storage device (e.g., aflash memory, a magnetic memory, an optical memory, etc.) that storesinformation and/or instructions for use by processor 320.

Storage component 340 may store information and/or software related tothe operation and use of device 300. For example, storage component 340may include a hard disk (e.g., a magnetic disk, an optical disk, amagneto-optic disk, a solid state disk, etc.), a compact disc (CD), adigital versatile disc (DVD), a floppy disk, a cartridge, a magnetictape, and/or another type of computer-readable medium, along with acorresponding drive. In some implementations, storage component 340 maystore TCE 220.

Input component 350 may include a component that permits device 300 toreceive information, such as via user input (e.g., a touch screendisplay, a keyboard, a keypad, a mouse, a button, a switch, amicrophone, etc.). Additionally, or alternatively, input component 350may include a sensor for sensing information (e.g., a global positioningsystem (GPS) component, an accelerometer, a gyroscope, an actuator,etc.). Output component 360 may include a component that provides outputinformation from device 300 (e.g., a display, a speaker, one or morelight-emitting diodes (LEDs), etc.).

Communication interface 370 may include a transceiver-like component(e.g., a transceiver, a separate receiver and transmitter, etc.) thatenables device 300 to communicate with other devices, such as via awired connection, a wireless connection, or a combination of wired andwireless connections. Communication interface 370 may permit device 300to receive information from another device and/or provide information toanother device. For example, communication interface 370 may include anEthernet interface, an optical interface, a coaxial interface, aninfrared interface, a radio frequency (RF) interface, a universal serialbus (USB) interface, a Wi-Fi interface, a cellular network interface, orthe like.

Device 300 may perform one or more processes described herein. Device300 may perform these processes in response to processor 320 executingsoftware instructions stored by a non-transitory computer-readablemedium, such as memory 330 and/or storage component 340. Acomputer-readable medium is defined herein as a non-transitory memorydevice. A memory device includes memory space within a single physicalstorage device or memory space spread across multiple physical storagedevices.

Software instructions may be read into memory 330 and/or storagecomponent 340 from another computer-readable medium or from anotherdevice via communication interface 370. When executed, softwareinstructions stored in memory 330 and/or storage component 340 may causeprocessor 320 to perform one or more processes described herein.Additionally, or alternatively, hardwired circuitry may be used in placeof or in combination with software instructions to perform one or moreprocesses described herein. Thus, implementations described herein arenot limited to any specific combination of hardware circuitry andsoftware.

The number and arrangement of components shown in FIG. 3 are provided asan example. In practice, device 300 may include additional components,fewer components, different components, or differently arrangedcomponents than those shown in FIG. 3. Additionally, or alternatively, aset of components (e.g., one or more components) of device 300 mayperform one or more functions described as being performed by anotherset of components of device 300.

FIGS. 4A-4C are diagrams of an example implementation of generating agraphical scene based on application programming interface instructions.As shown in FIG. 4, and by reference number 402, client device 210(e.g., TCE 220) may receive information defining values of a firstvariable Y1 (e.g., [2 3.5 2.5 3.8]) and values of a second variable Y2(e.g., [2.2 1.25 2.2 3.5]). As shown by reference number 404, clientdevice 210 may receive API instructions to generate a plot that includesa common axis (e.g., an x-axis) and two other axes (e.g., a left y-axisand a right y-axis). When client device 210 receives an API instructionthat is in the general format “yyaxis [active axis],” client device 210may generate an object tree that includes a dataspace object, associatedwith a left y-axis, and another dataspace object, associated with aright y-axis, as described in more detail in connection with FIG. 4C.The API instruction may further identify an active axis, of the righty-axis and the left y-axis (e.g., using a string of right or left, usinga value of 1 or 2, etc.). In some implementations, the API instructionmay identify an active dataspace object, of two or more dataspaceobjects associated with the object tree. In some implementations, adataspace object may be associated with two or more axes (e.g., two ormore ruler objects, etc.). Dataspace objects and ruler objects aredescribed in more detail below.

As shown, client device 210 (e.g., TCE 220) may receive the yyaxis APIinstruction specifying the left y-axis as the active axis (e.g., yyaxisleft). As further shown, client device 210 may receive an APIinstruction to plot the value of Y1 (e.g., bar(Y1), indicating togenerate a bar plot based on the values of Y1). Here, as shown in FIG.4B, client device 210 plots the value of Y1 in relation to the lefty-axis based on the left y-axis being the active axis. As further shown,client device 210 may receive an API instruction to identify the righty-axis as the active axis (e.g., yyaxis right), and may receive an APIinstruction to plot the value of Y2 (e.g., bar(Y2), indicating togenerate a bar plot based on the value of Y2). Here, as shown in FIG.4B, client device 210 plots the value of Y2 in relation to the righty-axis based on the right y-axis being the active axis.

As shown in FIG. 4B, client device 210 (e.g., TCE 220) may determine anupper limit and a lower limit of the left y-axis and the right y-axis,based on which to plot the values. Here, client device 210 determines alower limit of 0 and an upper limit of 4 for the left y-axis and for theright y-axis. As shown by reference numbers 406 and 408, client device210 may generate the left y-axis and the right y-axis based on thedetermined upper limits and lower limits, and may plot the valuesaccordingly.

As shown in FIG. 4B, client device 210 (e.g., TCE 220) may render agraphical scene based on the instructions received in connection withFIG. 4A by plotting Y1 and Y2 in relation to the axes. As shown byreference number 412, in the graphical scene, the value of Y1 may beplotted in relation to the common axis (e.g., the x-axis, shown byreference number 410) and the left y-axis. As shown by reference number414, the values of Y2 may be plotted in relation to the common axis andthe right y-axis.

As shown in FIG. 4C, client device 210 (e.g., TCE 220) may generate anobject tree based on the API instructions received in connection withFIG. 4A, and may store the object tree (e.g., locally, by providing theobject tree to server device 230, etc.). For example, client device 210may generate all or portions of the object tree based on receiving theyyaxis left API instruction. The object tree may include an Axes object416 (e.g., an Axes object, a PolarAxes object, etc.), dataspace objects418/420 (e.g., First Cartesian Dataspace 418 and Second CartesianDataspace 420), and a set of objects 422-430 (e.g., ruler objects, dataobjects, etc.). Axes object 416 may store information identifyingproperties relating to the graphical scene (e.g., axis locationproperties, axis limit properties, tick mark label properties, etc.). Insome implementations, Axes object 416 may store information identifyingwhich object, of objects 418-430, stores the values of the propertiesrelating to the graphical scene.

In some implementations, Axes object 416 may store instructions fordetermining particular objects to include in the object tree, and maystore instructions for determining values of properties to assign to theparticular objects. For example, Axes object 416 may store instructionsthat may cause client device 210 (e.g., TCE 220) to determine, based onthe yyaxis left API instruction, to generate an object tree thatincludes dataspace object 418 as well as dataspace object 420. Asanother example, based on receiving input identifying four input valuesfor Y1, Axes object 416 may store instructions that may cause clientdevice 210 to generate object 422 with a property value of [2 3.5 2.53.8], or to assign, to object 422, the property value of [2 3.5 2.53.8].

Objects 422-430 may store values of the properties relating to thegraphical scene. In some cases, a particular object may relate to one ormore axes, and may store properties for generating the one or more axesin the graphical scene. Here, object 426 relates to an x-axis of thegraphical scene, object 428 relates to a left y-axis of the graphicalscene, and object 430 relates to a right y-axis of the graphical scene.In some cases, a particular object may store values relating to data tobe plotted in the graphical scene (e.g., objects 422 and 424).

Dataspace objects 418/420 may identify operations and/or transformationsto perform to render or modify a graphical scene based on an APIinstruction. The operations and/or transformations may relate totransforming and/or changing properties identified by Axes object 416and stored by objects 422-430. For example, client device 210 (e.g., TCE220) may determine to modify a limit of the common axis in the renderedscene. Based on determining to modify the limit of the common axis,client device 210 may perform operations to transform values ofdataspaces 418/420 to determine a new limit of the common axis, the lefty-axis, and/or the right y-axis. In some implementations, client device210 may change values of the properties identified by Axes object 416and/or stored by objects 422-430 based on modifying the limit of thecommon axis in the rendered scene.

As one example, if an API instruction indicates to magnify the graphicalscene with regard to the x-axis, client device 210 (e.g., TCE 220) maydetermine a new upper limit and a new lower limit of the x-axis, and mayupdate Limits values stored by Axes object 416. Axes object 416 maycause the updated Limits values to be passed to objects 426-430 forstorage. When client device 210 is rendering the graphical scene, orwhen client device 210 is querying dataspace objects 418/420 for theLimits values, client device 210 (e.g., dataspace objects 418/420) mayobtain the updated Limits values from objects 426-430, based on whichclient device 210 may determine which values stored by objects 422 and424 to return and/or display.

The object tree may be generated for a particular coordinate system,and/or may include particular objects, based on a type of object 416.For example, if Axes object 416 is an Axes object, the object tree maybe generated for the Cartesian coordinate system, and may includeobjects related to rendering a graphical scene in the Cartesiancoordinate system (e.g., tick label objects, ruler objects, x-axisobjects, y-axis objects, x-value objects, y-value objects, etc.). Asanother example, if Axes object 416 is a Polar Axes object, as describedin more detail with regard to FIGS. 8A-16, client device 210 (e.g., TCE220) may generate the object tree in a polar coordinate system, and theobject tree may include objects related to rendering a graphical scenein the polar coordinate system (e.g., polar ruler objects, theta-axisobjects, r-axis objects, theta-value objects, r-value objects, etc.).

As shown, dataspace objects 418/420 may be connected with one or more ofobjects 422-430. Dataspace objects 418/420 may be capable of obtainingand/or causing client device 210 (e.g., TCE 220) to perform operationsbased on properties of objects 422-430 with which dataspace objects418/420 are connected in the figure by lines. Here, dataspace object 418is capable of obtaining properties of objects 422, 426, and 428, anddataspace object 420 is capable of obtaining properties of objects 424,426, and 430. Here, dataspace object 420 is connected with object 426 bya dotted line. This indicates that dataspace object 420 is capable ofobtaining and performing transformations based on values of object 426,despite not being connected with object 426 in the object tree. Forexample, dataspace object 420 may store handles to properties stored byobject 426, or the like. In some implementations, dataspace object 418may obtain properties of object 430 and/or dataspace object 420 mayobtain properties of object 428. In some implementations, an object treemay include a different quantity and/or arrangement of dataspaces. Forexample, an object tree may include one dataspace, three dataspaces,four dataspaces, or the like.

Object 426 is associated with the common axis (e.g., the x-axis) of thegraphical scene. Object 426 may provide stored properties to dataspaceobject 418, and/or to dataspace object 420, based on whether a changethat affects object 426 is related to the left y-axis (e.g., fordataspace object 418) or the right y-axis (e.g., for dataspace object420). In this way, client device 210 may obtain, based on dataspaceobjects 418/420, object properties based on modifications to objectsassociated with the left y-axis and/or the right y-axis, to facilitaterendering and/or modification of the graphical scene. As one possibleexample, if an API instruction causes a fifth value to be added to thearrays associated with Y1 and/or Y2, client device 210 may obtain, basedon dataspace objects 418/420, a Limits property of object 426 or anotherobject. When rendering the graphical scene, client device 210 (e.g., TCE220) may update dataspace objects 418/420 with a new upper limit and/orlower limit of the x-axis by finding a quantity of the values in thearrays associated with Y1 and/or Y2 stored by objects 422 and 424,and/or by obtaining the upper limit and/or lower limit values for thex-axis from object 426.

Objects 426, 428, and 430 may correspond to axes of the graphical scene(e.g., the x-axis, the left y-axis, and the right y-axis, respectively).Each of objects 426-430 may include a ruler object. Here, x-axis object426 includes an x-axis ruler object, left y-axis object 428 includes aleft y-axis ruler object, and right y-axis object 430 includes a righty-axis ruler object. In some implementations, objects 426, 428, and/or430 may be ruler objects. A ruler object may store properties related topositioning, labeling, and/or configuration of the corresponding axis,as described in more detail in connection with FIGS. 18-22, elsewhereherein (e.g., a particular format, content, and/or positioning of axislabels, a spacing, format, labeling, and/or style of markings (e.g.,tick marks) of the axis, a position the axis, a particular precision ofnumbers displayed in association with the axis, etc.).

As indicated above, FIGS. 4A-4C are provided merely as an example. Otherexamples are possible and may differ from what was described with regardto FIGS. 4A-4C. For example, client device 210 is described asperforming operations in connection with FIGS. 4A-4C. In someimplementations, one or more other devices, such as one or more serverdevices 230, may perform one or more of these operations independent ofor in combination with client device 210.

FIGS. 5A-5E are diagrams of an example implementation of modifying anobject tree and rendering a graphical scene based on applicationprogramming interface instructions. For the purposes of FIGS. 5A-5E,assume that the operations described in connection with FIGS. 4A-4C havebeen performed.

As shown in FIG. 5A, and by reference number 502, client device 210(e.g., TCE 220) may receive an API instruction (e.g., XLimMode=‘auto’)to cause client device 210 to automatically determine limits of thecommon x-axis. Based on the API instruction, client device 210, upondetermining that a property of the object tree has been modified, mayupdate dataspace objects 418/420 with a new upper limit and/or a newlower limit of the common x-axis to ensure that the common x-axis isproperly displayed based on the modified property. For example, when anew value is added to Y1 and/or Y2, client device 210 may determine tomodify an upper limit of the common x-axis, as stored by dataspaceobjects 418/420 and/or object 426 from 4 displayed values to 5 displayedvalues.

As shown by reference number 504, client device 210 (e.g., TCE 220) mayreceive an API instruction to modify values of Y1 and Y2. Here, a valueof 3 is appended as a fifth value of Y1, and a value of 12 is appendedas a fifth value of Y2. As shown by reference number 506, client device210 may receive API instructions to cause client device 210 to render amodified graphical scene based on the modifications to the values of Y1and Y2, and to automatically determine limits of the right y-axis (e.g.,yyaxis left, bar(Y1), yyaxis right, yLimMode(auto), and bar(Y2)).

As shown in FIG. 5B, client device 210 (e.g., TCE 220) may render amodified graphical scene, as compared to the graphical scene shown inFIG. 4B, based on the API instructions shown in FIG. 5A. Here, as shownby reference number 508, the value of 3, added as a fifth value of Y1,is plotted with regard to the left y-axis. As shown by reference number510, the value of 12, added as a fifth value of Y2, is plotted withregard to the right y-axis. As shown by reference number 512, clientdevice 210 may modify the x-axis based on the fifth values of Y1 and Y2by adding a fifth label and a fourth tick mark to the x-axis, and bymodifying an upper limit of the x-axis. As shown by reference number514, client device 210 may modify the right y-axis, based on themodification to Y2 and based on the yLimMode=‘auto’ API instruction, bychanging tick mark labels of the right y-axis and by modifying an upperlimit of the right y-axis.

FIGS. 5C-5E show object trees related to modifying the graphical scenesshown in FIGS. 4B and 5B based on the API instructions shown in FIG. 5A.

FIG. 5C shows an example implementation of an object tree that may begenerated based on API instructions received in FIG. 4A. As shown byreference number 516, each object, of the object tree of FIG. 4A/5C, maybe associated with a flag (e.g., a bit, a set of bits, etc.). Whenclient device 210 (e.g., TCE 220) modifies an object, client device 210may set the flag associated with the modified object and any objectrelated to (e.g., above, in the object tree) the modified object. Forexample, if a property associated with object 422 is modified, clientdevice 210 may set flags associated with objects 416 and 418, based onobjects 416 and 418 being hierarchically above client device 210 in theobject tree, as described in more detail below. Here, each flag is abit, and each bit is initialized to “0,” indicating that no object, ofthe object tree, has yet been modified.

Client device 210 (e.g., TCE 220) may set a flag based on modifying aproperty of an object, based on using an object to determine a propertyof another object, and/or in a situation where a property of an objectmay be modified based on a modification to another object, as describedin more detail in connection with FIGS. 5D and 5E, below.

FIG. 5D shows the object tree of FIG. 4A/5C as modified based on the APIinstructions received in FIG. 5A. As shown by reference numbers 518 and520, based on the API instructions received in FIG. 5A, client device210 (e.g., TCE 220) may modify properties of objects 422 and 424 toinclude the fifth value of Y1 and the fifth value of Y2, respectively.As shown by reference number 522, flags associated with objects 422 and424 may be set to indicate that objects 422 and 424 have been modified.Here, a flag associated with a bit value of “1” indicates that thecorresponding object has been modified, or may need to be modified toproperly render the graphical scene.

Based on modifying objects 422 and 424, client device 210 (e.g., TCE220) may modify other objects (e.g., to change tick marks, labels, upperlimits, lower limits, etc. of axes). As shown by reference number 524,based on the modification to objects 422 and 424, client device 210(e.g., TCE 220) may set flags corresponding to other objects that may beaffected by the modification of the modified object.

In some implementations, client device 210 may set flags according tooperations performed by Axes object 416. For example, client device 210may apply a rule, prescribed by Axes object 416, to determine whichobjects, of the object tree, shall be associated with a set flag basedon a modification to a particular object. In some implementations,client device 210 may apply the rule based on setting a flag associatedwith Axes object 416. For example, in a situation where client device210 sets a flag associated with Axes object 416, Axes object 416 maycause client device 210 to set flags associated with other objects, ofthe object tree.

Here, client device 210 may determine (e.g., based on setting a flagassociated with Axes object 416) that modifications to Y1 and Y2, whichinclude five values, cause the x-axis to be modified (e.g., to display afourth tick mark, to display a fifth label of “5,” etc.). Therefore,client device 210 sets flags corresponding to objects that may bemodified to generate the modified graphical scene based on the newvalues of Y1 and Y2 (e.g., Axes object 416, first dataspace 418, seconddataspace 420, data objects 422 and 424, X-axis object 426, and Y-axisright object 430).

As shown in FIG. 5E, client device 210 (e.g., TCE 220) may performoperations to modify properties of objects. For example, client device210 may modify properties of child objects 422-430 (e.g., based on childobjects 422-430 being associated with dirty bits). As shown by referencenumber 526, client device 210 may check object 422 and object 424 todetermine a modified upper limit and/or a modified lower limit of thex-axis (e.g., a lower limit of 1 and an upper limit of 5, as shown). Asshown by reference number 528, client device 210 may determine amodified upper limit and/or a modified lower limit of the left y-axisand the right y-axis, based on properties of Y1 and Y2, respectively.Here, the lower limit and the upper limit of the left y-axis areunchanged. The upper limit of the right y-axis is changed to a value of12, based on the value of 12 being included in the variable Y2.

To render the graphical scene shown in FIG. 5B based on the modifiedobject tree, client device 210 (e.g., TCE 220) may check each flaggedobject (e.g., each object that corresponds to a set flag) to determinewhether each flagged object stores modified properties. Client device210 may modify a graphical rendering tree based on flagged objects thatstore modified properties. Based on the modified objects of thegraphical rendering tree, client device 210 may render the modifiedgraphical scene shown in FIG. 5B.

In this way, client device 210 and/or TCE 220 may modify a graphicalscene, including a common axis and two or more other axes, based on anobject tree. Client device 210 and/or TCE 220 may generate and/or modifythe object tree based on API instructions, which may permit a user tospecify modifications using the API instructions, rather than usingresource-intensive workarounds. Thus, client device 210 will conserveprocessor power.

As indicated above, FIGS. 5A-5E are provided merely as an example. Otherexamples are possible and may differ from what was described with regardto FIGS. 5A-5E. For example, client device 210 is described asperforming operations in connection with FIGS. 5A-5E. In someimplementations, one or more other devices, such as one or more serverdevices 230, may perform one or more of these operations independent ofor in combination with client device 210.

FIG. 6 is a flow chart of an example process 600 for generating agraphical scene, including a common axis and at least two other axes,based on application programming interface instructions. In someimplementations, one or more process blocks of FIG. 6 may be performedby client device 210. In some implementations, one or more processblocks of FIG. 6 may be performed by another device or a set of devicesseparate from or including client device 210, such as server device 230.In some implementations, one or more process blocks of FIG. 6 may beperformed by one or more TCEs 220 executing on client device 210 and/orserver device 230.

As shown in FIG. 6, process 600 may include receiving input related to agraphical scene, the graphical scene including a common axis and atleast two other axes (block 610). For example, client device 210 (e.g.,TCE 220) may receive input related to a graphical scene. The graphicalscene may include a common axis and at least two other axes. In someimplementations, the graphical scene may be associated with a Cartesiancoordinate system. In some implementations, the graphical scene may beassociated with another coordinate system, such as a polar coordinatesystem, a spherical coordinate system, or the like.

The input may include an API instruction, in some implementations. Forexample, the input may include an API instruction to cause client device210 (e.g., TCE 220) to generate an object tree for rendering thegraphical scene, as described in connection with FIGS. 5A-5E, above. Insome implementations, the API instruction may indicate an axis, of theat least two other axes, as an active axis, as described in connectionwith reference number 420 of FIG. 4A, above. Client device 210 mayperform an operation, with regard to the active axis, based on the APIinstruction. For example, client device 210 may plot a data set withregard to the active axis, may modify objects of an object tree that areassociated with the active axis, or the like.

In some implementations, an API instruction may include a particular setof characters, and may cause client device 210 (e.g., TCE 220) toperform a particular action based on the particular set of characters.Example implementations of API instructions related to the APIinstruction yyaxis, and the associated actions, are shown in exampletable 1 below:

TABLE 1 API instruction Action yyaxis (arg) Generate a plot with twoy-axes and one common (x) axis; arguments specify an active axis (e.g.,yyaxis left, yyaxis right, yyaxis 1, yyaxis 2, etc.). ax = axes; Obtainsa handle to an [x/y/z] -axis object. [x/y/z] ruler handle = ax.[X/Y/Z]axis ax = gca; Selects axes object for most recently generated orselected graphical scene for modification ax.[X/Y/Z] Axis. Sets a valueof a property relating to the [Property] = (arg) [X/Y/Z]-axis to thevalue specified in (arg) ax.Y Axis[Index]. Sets a value (arg) for aproperty relating to a [Property] = (arg) Y-axis identified by Index(e.g., an integer). set(gca, ‘[Property]’, Sets a value of a property ofan object tree for ‘(arg)’) the axis that is most recently generated orselected. cla Reset color and line style properties for the active axis.cla reset Reset all properties for the active axis (e.g., all propertiesassociated with the above API instructions). reset(ax) Reset propertiesfor the active axis to default values.

In example table 1, API instructions may relate to a particular axis.For example, when an API instruction relates to an x-axis, the APIinstruction may include “x” in place of [x/y/z] and/or “X” in place of[X/Y/Z]. In some implementations, API instructions may relate to az-axis. A z-axis may include a second y-axis, a second x-axis, or athird axis that is perpendicular to one or more x-axes and one or morey-axes. In some implementations, API instructions may include additionalcharacters, fewer characters, and/or different characters. Additionally,or alternatively, API instructions may be associated with additionalactions, different actions, additional arguments, and/or differentarguments.

In some implementations, an API instruction may cause client device 210(e.g., TCE 220) to assign a particular value to a property of an objecttree. Example implementations of properties related to the yyaxis APIinstruction, and the associated values, are shown in example table 2below:

TABLE 2 Property Actions and values [X/Y/Z]MinorTick Toggle minor tickmarks on the active axis; values include on and off. [X/Y/Z]ScaleSpecify a scale of the active axis; arguments include linear and log.[X/Y/Z]Tick Specify tick mark locations on the active axis; argumentsinclude auto and a vector of values (e.g., [2 4 6], 0:10:100, etc.).[X/Y/Z]TickLabel Specify tick mark labels for the active axis; argumentsinclude an array of strings (e.g., [NE W S], etc.)[X/Y/Z]TickLabelRotation Specify tick mark label rotation angle for theactive axis; arguments include a scalar value in degrees or radians.[X/Y/Z]Color Specify color of outline and tick marks for the activeaxis; arguments include strings (e.g., ‘yellow’, ‘cyan’, etc.).[X/Y/Z]Dir Specify direction of increasing values along active axis;arguments include ‘normal’ and ‘reverse’. [X/Y/Z]Label Specify text fora label of the active axis; arguments include strings. [X/Y/Z]LimSpecify minimum and maximum axis limits for the active axis; argumentsinclude a two- element vector of the form [min max]. [X/Y/Z]LimModeSpecify method of determining minimum and maximum axis limits for theactive axis; arguments include ‘auto’ and ‘default’

In some implementations, API instructions may include additionalcharacters, fewer characters, and/or different characters. Additionally,or alternatively, API instructions may be associated with additionalactions, different actions, additional arguments, and/or differentarguments. Additionally, or alternatively, the API instructions shownabove may relate to a different axis (e.g., an x-axis may be associatedwith API instructions beginning with “xx” or “X,” rather than “yy” or“Y,” etc.).

In some implementations, the input may include data to be plotted in thegraphical scene. For example, the input may include one or more valuesto be plotted with regard to the common axis and at least one of theother axes. Additionally, or alternatively, the input may include valuesfor properties related to rendering the graphical scene. For example,the input may specify characteristics of elements of the graphical scene(e.g., a quantity, appearance, relative location, value, etc. of tickmarks, labels, plotted data points, etc.), as described in the exampletable above.

In some implementations, the graphical scene may be associated withmultiple common axes. For example, the graphical scene may include anx-axis and a z-axis as common axes, and a first y-axis and a secondy-axis as other axes. As another example, the graphical scene mayinclude a theta-axis and a z-axis as common axes, and a first r-axis anda second r-axis as other axes.

As further shown in FIG. 6, process 600 may include generating, based onthe input, an object tree that includes two or more dataspaces and oneor more objects, each of the two or more dataspaces corresponding to oneof the two or more other axes (block 620). For example, based on theinput, client device 210 (e.g., TCE 220) may generate an object tree.The object tree may include two or more dataspaces and one or moreobjects, as described in connection with FIGS. 4A-4C, above. In someimplementations, each of the two or more dataspaces may correspond toone or more of the other axes. For example, as in FIGS. 4A-4C, a firstdataspace may correspond to a left y-axis and a second dataspace maycorrespond to a right y-axis. Based on properties of the first dataspaceand/or the second dataspace, client device 210 may perform operations tomodify values associated with the one or more objects to generate and/ormodify the graphical scene, as described in FIGS. 4 and 5, above. Insome implementations, client device 210 may perform operations to modifyvalues associated with the one or more objects based on an objectincluded in the object tree (e.g., an Axes object, as described in moredetail above).

In some implementations, multiple dataspaces may obtain and transform(e.g., modify) values of a particular object. For example, theparticular object may correspond to the common axis of the graphicalscene, as described in connection with reference number 426 of FIG. 4C.By generating multiple dataspaces that modify values of the particularobject, client device 210 (e.g., TCE 220) may enable the object tree tomodify the particular object based on a modification to an objectassociated with one or more of the other axes, which may enable a userto manipulate the graphical scene using a reduced quantity of APIinstructions, thereby conserving processor resources.

In some implementations, a particular dataspace may modify a set ofobjects relating to a particular axis. For example, as described inconnection with FIGS. 4A-4C, above, a first dataspace may be associatedwith (e.g., capable of obtaining values from and/or causingmodifications to) objects corresponding to a left y-axis of a graphicalscene, and a second dataspace may be associated with objectscorresponding to a right y-axis of the graphical scene. The dataspacesmay perform operations related to modifying the objects of the objecttree and/or rendering the graphical scene, as described in more detailin connection with FIGS. 4A-4C and 5A-5E, above.

As further shown in FIG. 6, process 600 may include storing and/orproviding the object tree (block 630). For example, client device 210(e.g., TCE 220) may store and/or provide the object tree. In someimplementations, client device 210 may store the object tree locally.Additionally, or alternatively, client device 210 may provide the objecttree to another device (e.g., server device 230, etc.) for storageand/or display. In some implementations, client device 210 may provideinformation describing the object tree. For example, client device 210may provide the information via TCE 220, in a text file, in anexecutable file, or the like.

As further shown in FIG. 6, process 600 may include rendering thegraphical scene based on the object tree (block 640). For example,client device 210 (e.g., TCE 220) may render the graphical scene basedon the object tree. In some implementations, client device 210 maystore, locally, the rendered graphical scene. Additionally, oralternatively, client device 210 may provide information describing therendered graphical scene (e.g., for display via TCE 220, to serverdevice 230, etc.).

In some implementations, client device 210 (e.g., TCE 220) may generatea graphical rendering tree based on the object tree. For example, clientdevice 210 may include a general purpose processor and a differentprocessor from the general purpose processor, such as a specializedprocessing unit. The specialized processing unit may process thegraphical rendering tree to generate the graphical scene. The graphicalrendering tree may, in some implementations, be configured so that adesired (e.g., an optimal) performance may be achieved when thegraphical rendering tree is processed by the specialized processingunit. As one example, data associated with one of the multiple objects,of the object tree, may be converted to a format that provides adesired, e.g., best, performance from the specialized processing unit.Use of a graphical rendering tree, which may be configured to providethe desired performance from the specialized processing unit, prior torendering the graphical scene, may eliminate “on the fly” data/objectconversion which may slow down the rendering process.

As further shown in FIG. 6, process 600 may include providing thegraphical scene for display (block 650). For example, client device 210(e.g., TCE 220) may provide the graphical scene for display. In someimplementations, client device 210 may provide the graphical scene fordisplay via TCE 220. In some implementations, server device 230 mayrender the graphical scene, and may provide the rendered graphical scenefor display via TCE 220, hosted by client device 210. In this way,client device 210 and/or server device 230 may generate a graphicalscene that includes a common axis and two or more other axes based on anobject tree. The object tree may facilitate customization of thegraphical scene, which may reduce a quantity of API commands required tocustomize the graphical scene and, thus, reduce processor resourcerequirements.

Although FIG. 6 shows example blocks of process 600, in someimplementations, process 600 may include additional blocks, fewerblocks, different blocks, or differently arranged blocks than thosedepicted in FIG. 6. Additionally, or alternatively, two or more of theblocks of FIG. 6 may be performed in parallel.

FIG. 7 is a flow chart of an example process 700 for modifying agraphical scene, including a common axis and at least two other axes,based on application programming interface instructions. In someimplementations, one or more process blocks of FIG. 7 may be performedby client device 210. In some implementations, one or more processblocks of FIG. 7 may be performed by another device or a set of devicesseparate from or including client device 210, such as server device 230.In some implementations, one or more process blocks of FIG. 7 may beperformed by one or more TCEs 220 executing on client device 210 and/orserver device 230. For the purpose of FIG. 7, assume the operationsdescribed in connection with FIG. 6 have been performed.

As shown in FIG. 7, process 700 may include receiving input regarding agenerated graphical scene, the graphical scene including a common (e.g.,shared) axis and at least two other axes and being generated based on anobject tree (block 710). For example, client device 210 (e.g., TCE 220)may receive input regarding a graphical scene. The graphical scene mayinclude a previously generated graphical scene (e.g., previouslygenerated by client device 210, server device 230, etc.), as describedin FIG. 6, above. The input may include one or more API instructions(e.g., as described the table shown in connection with block 610 of FIG.6), based on which client device 210, or another device, may modifyobjects of an object tree associated with the graphical scene. Forexample, the input may include a yyaxis API instruction to select aparticular axis, of the other axes, as an active axis. Client device 210may perform operations with respect to the active axis, as described inmore detail in connection with FIGS. 5A-5E, above.

As further shown in FIG. 7, process 700 may include determining aparticular axis, of the other axes, to which the input is related (block720). For example, the input may relate to a particular axis, of theother (e.g., non-shared) axes. Client device 210 (e.g., TCE 220) mayidentify the particular axis in order to modify objects related to theparticular axis, and/or the common axis, based on the input. In someimplementations, the input may identify the particular axis (e.g.,yyaxis left, yyaxis right, etc.). Additionally, or alternatively, clientdevice 210 may determine the particular axis based on the input. Forexample, client device 210 may determine that the input modifies a valueof a variable that is plotted with regard to the particular axis, andmay accordingly determine that the input is related to the particularaxis.

As further shown in FIG. 7, process 700 may include determining a firstobject, associated with a dataspace and associated with the particularaxis, to modify based on the input (block 730). For example, the objecttree of the graphical scene may include a variety of objects. The inputmay relate to an object, of the variety of objects. Client device 210(e.g., TCE 220) may determine a first object to modify based on theinput. The first object may be associated with a dataspace of the objecttree, and may be associated with the particular axis. For example, thefirst object may store one or more properties related to the particularaxis and/or the input.

In some implementations, the input may identify the first object. Forexample, the input may include a textual string of characters thatidentifies the first object (e.g., by a handle object that identifiesthe first object, by a hierarchical location of the first object in theobject tree, by a name of the first object, etc.). As another example,the input may include a value to be assigned to a variable, and clientdevice 210 (e.g., TCE 220) may identify an object associated with thevariable. In some implementations, client device 210 may identify thefirst object based on an active axis. For example, the input may includean API instruction to pan, magnify, etc. with respect to an active axis,and client device 210 may identify the first object based on arelationship between the first object and the active axis.

As further shown in FIG. 7, process 700 may include determining whetherone or more second objects, of the object tree, are to be modified basedon the input (block 740). For example, a modification to a graphicalscene may require modifications to multiple objects of an object treecorresponding to the graphical scene. Client device 210 (e.g., TCE 220)may determine a particular object to modify based on the input thatidentifies the modification to the graphical scene. However, to modifythe graphical scene according to the input, client device 210 may needto modify one or more other objects. Client device 210 may determine theother objects to be modified based on the input.

As an example, consider FIG. 5A. As shown by reference number 504 ofFIG. 5A, client device 210 (e.g., TCE 220) receives input that includesmodifications to values of Y1 and Y2. As shown in FIG. 5D, client device210 modifies properties, stored by objects 422 and 424 of the objecttree, based on the input. To display the modified values of Y1 and Y2 asshown in FIG. 5B, client device 210 may modify objects associated withthe x-axis and the right y-axis. For example, client device 210 maydetermine new upper limits and/or new lower limits of the x-axis and/orthe right y-axis, and may modify objects of the object tree based on thenew upper limits and/or the new lower limits of the data associated withobjects 422 and 424. In some cases, a particular input may modify valuesof the left y-axis and the right y-axis (e.g., based on a user-specifieddata aspect ratio change, etc.). In such a case, client device 210 maydetermine new upper limits and/or new lower limits of the x-axis, theright y-axis, and the left y-axis.

As further shown in FIG. 7, process 700 may include performing one ormore operations, based on the dataspace and based on the first objectand/or the one or more second objects, to generate one or more modifiedobjects (block 750). For example, a dataspace, of the object tree, mayperform (e.g., may cause client device 210 and/or TCE 220 to perform)one or more operations. The one or more operations may modifyproperties, of the particular object and/or the one or more otherobjects, based on the input. For example, as in FIG. 5E, client device210 may determine one or more objects, of the objects with set flags inFIG. 5D, to modify based on the instruction, and may perform one or moreoperations, based on dataspaces 418/420, to modify properties of theobjects.

As another example, consider the following lines of program code:

-   -   1 yyaxis right    -   2 ax.YAxis(1).Limits=[0,1];    -   3 ax.YAxis(2).Limits=[2,10];    -   4 ax.YLim        -   ans=[2,10]    -   5 yyaxis left    -   6 ax.YLim        -   ans=[0,1]    -   7 ax.YAxis(2).Limits        -   ans=[2,10]

In the above example, client device 210 (e.g., TCE 220) receives an APIinstruction in line 1 to specify an active axis (e.g., yyaxis right, tospecify a right y-axis). In line 2 and line 3, client device 210receives API instructions to specify upper limits and lower limits ofleft and righty-axes (e.g., ax.YAxis(1).Limits=[0, 1]; andax.YAxis(2).Limits=[2, 10];, to specify upper limits and lower limits ofthe left y-axis and the right y-axis, respectively). Here, client device210 may modify objects of a corresponding object tree based on thevalues identified in the API instructions (e.g., may set values of theLimits property of a first object to [0, 1], and may set values of theLimits property of a second object to [2, 10], based on an Axes objectof the corresponding object tree causing client device 210 to modify theobjects). In line 4, client device 210 receives an API instruction todisplay upper and lower limits of the active axis, which is the righty-axis, as specified in line 1 (e.g., ax.YLim). As shown, client device210 provides, for display, the upper limit and the lower limit of theright y-axis.

As further shown in the above example, in lines 5 and 6, client device210 (e.g., TCE 220) receives API instructions to specify the left y-axisas an active axis (e.g., yyaxis left) and to cause client device 210 toprovide upper and lower limits of the active axis (e.g., ax.YLim). Asshown, client device 210 provides the upper limit and the lower limit ofthe left y-axis accordingly. As shown, in line 7, client device 210receives an API instruction to provide the upper limit and the lowerlimit of the right y-axis (e.g., ax.YAxis(2)Limits), and provides theupper limit and the lower limit based on the API instruction.

As further shown in FIG. 7, process 700 may include rendering a modifiedgraphical scene based on the object tree (block 760). For example, basedon the object tree, including the one or more modified objects, clientdevice 210 (e.g., TCE 220) may render a modified graphical scene. Themodified graphical scene may differ from the generated graphical sceneof block 710 based on the input. For example, if the input includes anAPI instruction to magnify the graphical scene with regard to a righty-axis, the modified graphical scene may include a modified righty-axis, a modified x-axis, and one or more data points that are plottedin relation to the modified right y-axis and the modified x-axis.

In some implementations, client device 210 (e.g., TCE 220) may generatea modified graphical rendering tree. For example, client device 210 maymodify objects of the graphical rendering tree that correspond to theone or more modified objects. In some implementations, client device 210may modify the objects of the graphical rendering tree based on setflags associated with objects of the object tree. Based on the graphicalrendering tree, including the modified objects, client device 210 maygenerate the modified graphical scene.

As further shown in FIG. 7, process 700 may include providing, fordisplay, the modified graphical scene (block 770). For example, clientdevice 210 (e.g., TCE 220) may provide, for display, the modifiedgraphical scene (e.g., via a display of client device 210, via TCE 220,etc.). In some implementations, server device 230 may render thegraphical scene, and may provide the rendered graphical scene to clientdevice 210 for display (e.g., via TCE 220, etc.). In this way, clientdevice 210 may modify a common axis and another axis of a graphicalscene based on API instructions and based on one or more dataspacesassociated with the common axis and the other axis, which may improveefficiency of client device 210 by reducing reliance, by a user, onresource-intensive workarounds to customize the graphical scene.

Although FIG. 7 shows example blocks of process 700, in someimplementations, process 700 may include additional blocks, fewerblocks, different blocks, or differently arranged blocks than thosedepicted in FIG. 7. Additionally, or alternatively, two or more of theblocks of FIG. 7 may be performed in parallel.

FIGS. 8A and 8B are diagrams of an example implementation of generatingan object tree and rendering a graphical scene, including specified axislimits, based on application programming interface instructions.

As shown in FIG. 8A, and by reference number 810, client device 210 mayreceive an API instruction to render a graphical scene that includes aplot in a polar coordinate system (e.g., “polarplot(th, dB)”). Based onreceiving the API instruction to render the graphical scene, clientdevice 210 may generate an object tree in a polar coordinate system, asdescribed in more detail in connection with FIG. 8B.

As shown by reference number 820, client device 210 (e.g., TCE 220) mayreceive an API instruction to modify an upper limit and a lower limit ofan r-axis of the plot (e.g., set(gca, ‘RLim’, [−10,5])). The r-axis maybe associated with r-values, such as real number values, integer values,or the like. Based on receiving the API instruction to modify the upperlimit and the lower limit, client device 210, based on, for example, anAxes object, may perform a transformation with regard to a property ofan object of the object tree, and/or may modify a value of a property ofone or more objects, as described in more detail in connection with FIG.8B. As shown by reference number 830, the r-axis of the plot displayedin the graphical scene may include a lower limit of −10. As shown byreference number 840, the r-axis of the plot may include an upper limitof 5.

As shown in FIG. 8B, and by reference number 850, client device 210(e.g., TCE 220) may generate an object tree in a polar coordinate systembased on the “polarplot” API instruction. Assume that client device 210determines that the “polarplot” API instruction includes a text stringof “polar,” and generates the object tree in the polar coordinate systemaccordingly. In some implementations, client device 210 may storeinformation identifying API instructions that are associated with thepolar coordinate system, and may determine that the “polarplot” APIinstruction relates to the polar coordinate system accordingly.

As shown, the object tree may include a PolarAxes object. The PolarAxesobject in the polar coordinate system may correspond to an Axes objectin an object tree of a Cartesian coordinate system. As shown, object 850may store properties related to the graphical scene. Here, object 850includes a reference to a Limits property that defines a lower limit(e.g., −10) and an upper limit (e.g., 5) of the r-axis shown in FIG. 8A(e.g., similarly to the Limits property in an object tree of a Cartesiancoordinate system, as described above).

In some implementations, client device 210 (e.g., TCE 220) may generatethe PolarAxes object based on the API instruction including the stringof “polar,” and the PolarAxes object may generate the objects based onan object tree for a Cartesian coordinate system. For example, clientdevice 210 may store a set of operations for generating an object treein a Cartesian coordinate system. The PolarAxes object may modify theset of operations to generate the objects of the object tree for thepolar coordinate system. For example, when the set of operations relateto generating an object for an x-axis, the PolarAxes object may generatean object for a theta-axis. The theta-axis may be associated withtheta-values, such as radian values, degrees, or the like. When the setof options relate to generating an object for a y-axis, the PolarAxesobject may generate an object for an r-axis. In this way, client device210 may generate an object tree for a polar coordinate system based onan object tree for a Cartesian coordinate system, which simplifiesgeneration/modification of graphical scenes in the polar coordinatesystem.

As shown by reference number 860, the object tree may include adataspace object that is associated with one or more objects. As shownby reference number 870, the dataspace object is associated with a“Data” object that stores properties relating to plotted data. Thedataspace object stores properties that identify the propertiesassociated with the “Data” object and/or the PolarAxes object, andpermits client device 210 (e.g., TCE 220) to perform transformationswith regard to the properties associated with the “Data” object.

In this way, client device 210 (e.g., TCE 220) may generate and/ormodify an object tree, based on API instructions, to facilitaterendering and/or modification of a graphical scene that includes a polarplot. The object tree may be configured to reduce a quantity of APIinstructions and/or operations required to render and/or modify thegraphical scene, which will conserve processor resources.

As indicated above, FIGS. 8A and 8B are provided merely as an example.Other examples are possible and may differ from what was described withregard to FIGS. 8A and 8B. For example, client device 210 is describedas performing operations in connection with FIGS. 8A and 8B. In someimplementations, one or more other devices, such as one or more serverdevices 230, may perform one or more of these operations independent ofor in combination with client device 210.

FIGS. 9A and 9B are diagrams of an example implementation of generatingan object tree and rendering a graphical scene, including multiple,concurrently plotted data sets, based on application programminginterface instructions.

As shown in FIG. 9A, and by reference number 910, client device 210(e.g., TCE 220) may receive an API instruction to render a graphicalscene that includes a polar plot (e.g., polaraxes). Based on the APIinstruction to render the graphical scene, client device 210 maygenerate an object tree in a polar coordinate system, as described inmore detail in connection with FIGS. 8B and 9B. As shown by referencenumber 920, client device 210 may receive an API instruction toconcurrently plot multiple data sets on the polar plot (e.g., “holdon”). As shown by reference number 930, client device 210 may receiveAPI instructions to plot a first data set and a second data set (e.g., afirst data set of r1 and a second data set of r2).

Here, assume that the “hold on” command is an API instruction,associated with a graphical scene in a Cartesian coordinate system, toconcurrently plot multiple sets of data. The “hold on” API instructionmay malfunction when client device 210 (e.g., TCE 220) attempts toconcurrently plot multiple polar data sets using an object tree in aCartesian coordinate system. By generating the object tree in the polarcoordinate system based on the object tree in the Cartesian coordinatesystem (e.g., by generating the object tree in the polar coordinatesystem, and using a base class shared with the Cartesian coordinatesystem), client device 210 causes the “hold on” command to function asexpected when concurrently plotting multiple polar data sets.

Based on receiving the API instruction to concurrently plot the multipledata sets, client device 210 may first plot the first data set, and maysecond plot the second data set without removing the plot of the firstdata set. Client device 210 may provide the graphical scene, includingthe polar plot, for display, as shown by reference number 940. As shown,TCE 220 may represent the first data set using a line having a firstappearance (e.g., a dashed pattern), and may represent the second dataset using a line having a second appearance (e.g., a solid pattern).

As shown in FIG. 9B, client device 210 may generate an object tree basedon the “PolarAxes” API instruction. Assume that client device 210determines that the “PolarAxes” API instructions includes a string of“polar,” and generates the object tree in the polar coordinate systemaccordingly. As shown, objects of the object tree may store stylingproperties relating to corresponding lines in the graphical scene (e.g.,a line type of the lines associated with the two plotted data sets). Asshown by reference number 950, the object tree may include a firstobject that stores properties related to the first data set (e.g., avalue of r1, the, etc.). As shown by reference number 960, the objecttree may include a second object that stores properties related to thesecond data set (e.g., a value of r2, di, etc.).

By generating an object tree in the polar coordinate system, clientdevice 210 (e.g., TCE 220) may permit a user to cause client device 210to first plot the first data set, then to second plot the second dataset, using the “hold on” command (e.g., may permit the user to firstplot the first data set, then to second plot the second data set). Anobject tree, generated based on a Cartesian coordinate system, may notbe capable of concurrently plotting the multiple data sets in the polarcoordinate system. In this way, client device 210 improves versatilityof the API, and conserves processor resources by reducing a quantity ofAPI instructions required to concurrently plot the multiple data sets inthe polar coordinate system.

In some implementations, client device 210 (e.g., TCE 220) may plot afirst data set with regard to a polar coordinate system based onreceiving an API instruction (e.g., polarplot(arg)), may receive the“hold on” API instruction, and may then receive another API instructionto plot a second data set in an unspecified coordinate system (e.g.,plot(arg)). In such a case, client device 210 may plot the second dataset with regard to the Cartesian coordinate system. In this way, clientdevice 210 simplifies plotting of data sets, which improves userexperience and conserves processor resources that are otherwise used formore time-intensive workarounds.

In some implementations, client device 210 (e.g., TCE 220) may plot afirst data set with regard to the Cartesian coordinate system based onreceiving an API instruction (e.g., plot(arg)), may receive the “holdon” API instruction, and may then receive another API instruction toplot a second data set in the polar coordinate system (e.g.,polarplot(arg)). In such a case, client device 210 may generate an error(e.g., based on receiving the API instruction to plot in the polarcoordinate system after receiving the API instruction to plot in theCartesian coordinate system). In this way, client device 210 preventsusers from plotting in the polar coordinate system after plotting in theCartesian coordinate system, which reduces user error.

In some implementations, client device 210 (e.g., TCE 220) may receivean API instruction to generate an object tree in the polar coordinatesystem (e.g., ax=PolarAxes, etc.), and may receive an API instruction togenerate a plot that is associated with a Cartesian coordinate system(e.g., plot(ax,th,r)). In such a case, client device 210 may generatethe plot in the polar coordinate system (e.g., based on the object treeassociated with the previous API instruction being associated with thepolar coordinate system). In this way, client device 210 reducesreliance on costly workarounds, which conserves processor resources andimproves user experience.

In some implementations, client device 210 (e.g., TCE 220) may plot adata set with regard to multiple, different coordinate systems. Forexample, assume that client device 210 generates a first plot in aCartesian coordinate system, and assume that client device 210 generatesa second plot in a polar coordinate system. Assume further that clientdevice 210 receives an API instruction to plot a data set with regard tothe first plot. In that case, client device 210 may associate the dataset with XData and YData properties of an object tree. Now assume thatclient device 210 receives another API instruction to plot the data setwith regard to the second plot. In that case, client device 210 mayassociate the data set with ThetaData and RData properties of an objecttree. In the above example, a user may interact with the first plot andthe second plot using shared API instructions, in some cases. Forexample, a “hold on” API instruction, a “plot” API instruction, or thelike, may cause client device 210 to perform the same action with regardto the first plot and with regard to the second plot. In this way,client device 210 improves versatility of API instructions, whichimproves performance of client device 210 and reduces user error anduser reliance on costly workarounds.

As indicated above, FIGS. 9A and 9B are provided merely as an example.Other examples are possible and may differ from what was described withregard to FIGS. 9A and 9B. For example, client device 210 is describedas performing operations in connection with FIGS. 9A and 9B. In someimplementations, one or more other devices, such as one or more serverdevices 230, may perform one or more of these operations independent ofor in combination with client device 210.

FIG. 10 is a diagram of an example implementation of generating anobject tree and rendering a graphical scene, including a specifiedpattern and a specified layer, based on application programminginterface instructions.

As shown in FIG. 10, and by reference number 1010, client device 210 mayreceive an API instruction to render a graphical scene that includes apolar plot (e.g., “polarplot(th, r)”). The polar plot may plot a dataset (e.g., r) in a polar coordinate system. Based on the API instructionto render the graphical scene, client device 210 (e.g., TCE 220) maygenerate an object tree in a polar coordinate system, in a mannersimilar to that described above in connection with FIGS. 8B and 9B. Asshown by reference number 1020, client device 210 may receive an APIinstruction to specify a color of the polar axes and/or layer, based onwhich to display the plotted data set (e.g., “set(gca, ‘color’,[0.9,0,9,0.9], ‘Layer’, ‘top’)”). Here, the API instruction specifies agray color and a top layer.

The color may specify the color of the background and/or lines of thepolar axes. The layer may specify a particular layer, of the graphicalscene, in which to place the plotted data set. Elements of the graphicalscene that are placed in layers below the particular layer may bedisplayed as if covered by the plotted data set, and the plotted dataset may be displayed as if covered by elements of the graphical scenethat are placed in layers above the particular layer. As shown byreference number 1030, client device 210 may provide, for display, thegraphical scene, including the plotted data set and the color of thepolar axes.

Client device 210 (e.g., TCE 220) may generate an object tree in a polarcoordinate system based on the API instruction to generate the graphicalscene. For example, the object tree may resemble the object tree shownin FIGS. 8B and 9B. An object (e.g., a PolarAxes object) may storeproperties related to the specified color of the axes background andrelated to the specified layer of the plotted data sets (e.g., aproperty that associates the grids and decorations of the polar axeswith a top layer above the graph of r).

By generating the object tree in the polar coordinate system, clientdevice 210 (e.g., TCE 220) may permit a user to specify properties ofthe plotted data set, such as patterns, layers, or the like, usingsyntax that may be analogous to syntax used to specify properties ofplotted data sets in Cartesian coordinates. An object tree, generatedbased on a Cartesian coordinate system, may not be capable of generatinga polar plot according to the specified patterns, layers, or the like.In this way, client device 210 improves versatility of the graphicalscene and conserves processor resources by reducing a quantity of APIinstructions required to generate the polar plot according to thespecified properties.

As indicated above, FIG. 10 is provided merely as an example. Otherexamples are possible and may differ from what was described with regardto FIG. 10. For example, client device 210 is described as performingoperations in connection with FIG. 10. In some implementations, one ormore other devices, such as one or more server devices 230, may performone or more of these operations independent of or in combination withclient device 210.

FIGS. 11A-11F are diagrams of an example implementation of generatingand modifying an object tree, and rendering graphical scenes, includingpolar plots, based on application programming interface instructions.

As shown in FIG. 11A, and by reference number 1105, client device 210(e.g., TCE 220) may receive an API instruction to generate a graphicalscene that includes a polar plot (e.g., “polarplot(th, r)”). The polarplot may include a data set (e.g., r) that may be plotted with regard tovalues of theta (e.g., th) in a polar coordinate system. Based on theAPI instruction to generate the graphical scene, client device 210 maygenerate an object tree in a polar coordinate system, as described inmore detail in connection with FIGS. 8B and 11F. Client device 210 maygenerate the graphical scene based on the object tree.

As shown by reference number 1110, client device 210 may receive an APIinstruction to specify a location of a zero value of a theta-axis of theplot (e.g., “set(gca, ‘ThetaZeroLocation’, ‘top’”). The API instructionmay specify an object tree, associated with the graphical scene, tomodify. For example, the property “gca” may cause client device 210 tomodify the polar plot, based on the polar plot being the most recentlychosen axes object of a graphical scene.

The API instruction may further identify an object and a property of theobject to modify. Here, the API instruction specifies a property of“ThetaZeroLocation” (e.g., as shown in FIG. 11F) and a value to assignto the property (e.g., a value of “top”). As shown by reference number1115, client device 210 may render the graphical scene, and may provide,for display, the graphical scene. As shown, the graphical scene mayinclude a zero value of the theta-axis at a top of the polar plot.

As shown in FIG. 11B, and by reference number 1120, client device 210(e.g., TCE 220) may receive another API instruction to modify thelocation of the zero value of the theta axis. Here, the other APIinstruction specifies the property “ThetaZeroLocation” (shown in FIG.11F) and a value to assign to the property (e.g., a value of “right”).Assume that client device 210 modifies the property based on the APIinstruction. As shown by reference number 1125, client device 210 mayre-render the graphical scene based on the modified property, and mayprovide the modified graphical scene for display.

As shown in FIG. 11C, and by reference number 1130, client device 210(e.g., TCE 220) may receive an API instruction to specify tick marklabels to display in relation to the theta-axis (e.g., “set(gca,‘ThetaTickLabels’, {‘East’, ‘North’, ‘West’, ‘South’})”). Here, the APIinstruction specifies the property “ThetaTickLabels” (shown in FIG. 11F)and values to assign to the property (e.g., values of “East,” “North,”“West,” and “South”). Assume that client device 210 modifies the“ThetaTickLabels” property of an object of the object tree based on theAPI instruction. As shown by reference number 1135, client device mayre-render the graphical scene based on the modified property.

As shown in FIG. 11D, and by reference number 1140, client device 210(e.g., TCE 220) may receive an API instruction to specify a direction(e.g., clockwise, counterclockwise, etc.) based on which to display dataplotted with respect to the theta-axis. Here, the API instructionspecifies the property “ThetaDir” (shown in FIG. 11F) and a value toassign to the property (e.g., a value of “clockwise,” as compared to adefault value of, for example, “counterclockwise”). Assume that clientdevice 210 modifies the property based on the API instruction. As shownby reference number 1145, client device may re-render the graphicalscene based on the modified property, and may display the data and thelabels of the theta-axis in a reverse order as compared to the order ofthe labels shown in FIGS. 11A-11C.

As shown in FIG. 11E, and by reference number 1150, client device 210(e.g., TCE 220) may receive another API instruction to specify thedirection based on which to display the tick mark labels of thetheta-axis. Here, the API instruction specifies the property “ThetaDir”(shown in FIG. 11F) and a value to assign to the property (e.g., a valueof “counterclockwise,” as compared to the value of “clockwise” assignedin FIG. 11D). Assume that client device 210 modifies the property basedon the API instruction. As shown by reference number 1155, client devicemay re-render the graphical scene based on the modified property, andmay display the labels of the theta-axis in a counterclockwise order ascompared to the order of the labels shown in FIG. 11D.

FIG. 11F shows an example object tree that may be generated and/ormodified based on the API instructions received in connection with FIGS.11A-11E. As shown, the object tree includes an object that storesproperties related to the plotted data set (e.g., r). As shown byreference number 1160, the object tree includes an object that storesreferences to properties (e.g., shown here by ellipses) related to thelocation of the zero value of the theta-axis (e.g.,“ThetaZeroLocation”). Here, the property is set to a value of “0.” Insome implementations, the property may be set to another value (e.g.,“90,” as shown in FIG. 11B, “135,” “top,” “pi,” etc.).

As further shown, the object stores a “ThetaDir” property relating to adirection of increasing tick mark values on the theta-axis. Here, theproperty is set to a value of “counterclockwise.” As also shown, theobject stores a property related to assigning tick mark labels of thetheta-axis (e.g., “ThetaTickLabels”). Here, the property is set to avalue of “default.” In some implementations, the property may be set toanother value (e.g., “East,” “North,” “West,” “South,” as described inFIG. 11C, a string of text, etc.). In some implementations, one or moreof the properties may be stored by objects of the example object tree,and the object may store information identifying the objects that storethe properties.

By generating the object tree in the polar coordinate system, clientdevice 210 (e.g., TCE 220) permits a user to specify properties of thepolar-axis, such as content of tick mark labels, a directional order ofthe tick mark labels, a relative location of the zero value of the tickmark labels, or the like. In some implementations, client device 210 maynot be capable of generating or modifying a polar plot according to thespecified properties based on an object tree that is generated in theCartesian coordinate system. In this way, client device 210 improvesversatility of the graphical scene, and conserves processor resources byreducing a quantity of API instructions required to generate the polarplot according to the specified properties.

As indicated above, FIGS. 11A-11F are provided merely as an example.Other examples are possible and may differ from what was described withregard to FIGS. 11A-11F. For example, client device 210 is described asperforming operations in connection with FIGS. 11A-11F. In someimplementations, one or more other devices, such as one or more serverdevices 230, may perform one or more of these operations independent ofor in combination with client device 210.

FIG. 12 is a diagram of an example implementation of rendering agraphical scene, including tick mark labels in a specified numericalformat, based on application programming interface instructions.

As shown in FIG. 12, and by reference number 1210, client device 210(e.g., TCE 220) may receive an API instruction to render a graphicalscene that includes a polar plot (e.g., “polarplot(th, r)”). The polarplot may include a data set (e.g., th, r) to be plotted with regard to apolar coordinate system. As shown, assume that the plotted data set ofth is expressed in radians (e.g., as opposed to degrees). As furthershown, client device 210 receives an API instruction (e.g., “ax=gca”) toobtain a handle, associated with the generated polar plot, to modify.Based on the API instruction to render the graphical scene, clientdevice 210 may generate an object tree in a polar coordinate system, asdescribed in more detail, for example, with regard to FIG. 8B, above.

As shown by reference number 1220, client device 210 (e.g., TCE 220) mayreceive an API instruction to specify a unit (e.g., degrees, radians,degrees/minutes/seconds, decimals, etc.) based on which to plot thepolar data (e.g., ax.ThetaAxisUnits=‘radians’;). Here, the APIinstruction specifies a property of “ThetaAxisUnits” and a value toassign to the property (e.g., a value of “radians,” as compared, forexample to a value of “degrees,” a value of “dms,” or the like). Asshown by reference number 1230, based on the value of “radians,” clientdevice 210 may plot the data set in radians, rather than, for example,degrees, degrees/minutes/seconds, or the like.

In this way, client device 210 (e.g., TCE 220) may generate thegraphical scene according to a numerical system in which the data set isexpressed, which improves versatility of the graphical system and/orconserves processing resources, by reducing user reliance onresource-intensive workarounds to convert and plot data sets that areexpressed in numerical systems other than a particular numerical system.

As indicated above, FIG. 12 is provided merely as an example. Otherexamples are possible and may differ from what was described with regardto FIG. 12. For example, client device 210 is described as performingoperations in connection with FIG. 12. In some implementations, one ormore other devices, such as one or more server devices 230, may performone or more of these operations independent of or in combination withclient device 210.

FIGS. 13A and 13B are diagrams of an example implementation ofgenerating an object tree and rendering a graphical scene, includingspecified line widths, based on application programming interfaceinstructions.

As shown in FIG. 13A, and by reference number 1310, client device 210(e.g., TCE 220) may receive an API instruction to render a graphicalscene that includes a polar plot (e.g., “polarplot(th, [r1 r2])”). Thepolar plot may plot a first data set (e.g., r1) and a second data set(e.g., r2) in a polar coordinate system. Based on the API instruction torender the graphical scene, client device 210 may generate an objecttree in a polar coordinate system, as described in more detail inconnection with FIGS. 8B and 13B.

As shown by reference number 1320, client device 210 (e.g., TCE 220) mayreceive an API instruction (e.g., set(gca, ‘Line Width’, 2)) to specifya line width based on which to display lines associated with the axes(e.g., a default line width of “1,” a thicker line width of “2,” athinner line width of “0.5,” etc.). Here, the API instruction specifiesthe property, of an object in the object tree, of “Line Width” (shown inFIG. 13B) and a value to assign to the property (e.g., a value of “2,”as compared to a default value of “1”), as shown by reference number1330. Assume that client device 210 modifies the “Line Width” propertybased on the API instruction. As shown by reference number 1340, clientdevice 210 may render the graphical scene based on the modifiedproperty, and may display the lines representing the axes with a thickerline width than a line width associated with other plotted data sets,such as the data set shown as plotted in FIG. 12.

As shown in FIG. 13B, client device 210 (e.g., TCE 220) may generate anobject tree, in a polar coordinate system, based on the API instructionto generate the graphical scene. As shown, the object tree may includean object that stores properties related to the plotted data sets. Asshown by reference number 1350, the object may store properties relatedto the specified line width of each plotted data set. Here, the objectstores a property that associates the data sets of r1 and r2 with a lineweight of 2.

By generating the object tree in the polar coordinate system, clientdevice 210 (e.g., TCE 220) may permit a user to specify properties ofthe plotted data set, such as line weights, or the like. An object treethat is generated based on a Cartesian coordinate system may not becapable of generating a polar plot according to the specifiedproperties. In this way, client device 210 improves versatility of thegraphical scene, and/or conserves processor resources by reducing aquantity of API instructions required to generate the polar plotaccording to the specified properties.

As indicated above, FIGS. 13A and 13B are provided merely as an example.Other examples are possible and may differ from what was described withregard to FIGS. 13A and 13B. For example, client device 210 is describedas performing operations in connection with FIGS. 13A and 13B. In someimplementations, one or more other devices, such as one or more serverdevices 230, may perform one or more of these operations independent ofor in combination with client device 210.

FIG. 14 is a diagram of an example implementation of rendering agraphical scene, including a specified range of a data set, based onapplication programming interface instructions.

As shown in FIG. 14, and by reference number 1410, client device 210(e.g., TCE 220) may receive an API instruction to generate a graphicalscene that includes a polar plot (e.g., “polarplot(th, r)”). The polarplot may include a data set (e.g., r) to be plotted in a polarcoordinate system. Based on the API instruction to generate thegraphical scene, client device 210 may generate an object tree in apolar coordinate system, as described in more detail elsewhere herein,such as in connection with FIGS. 8B and 11F. Assume that an object ofthe object tree stores a property related to a range of values, of thetheta axis, based on which to generate the polar plot (e.g.,“ThetaLim”).

As shown by reference number 1420, client device 210 (e.g., TCE 220) mayreceive an API instruction to plot a specified portion of the theta-axis(e.g., “set(gca, ‘ThetaLim’, [−90 90])”). Here, the API instructionspecifies the “ThetaLim” property and a value to assign to the property(e.g., a numerical value of “[−90 90],” indicating to plot values of thedata set that occur, for example, between theta-values of −90 degreesand 90 degrees), as shown by reference number 1430. As shown byreference number 1440, client device 210 may provide the graphical sceneincluding theta-values between −90 degrees and 90 degrees.

In this way, client device 210 (e.g., TCE 220) may render the graphicalscene according to a range of values of the theta-axis, which improvesversatility of the graphical system and/or conserves processingresources, by reducing user reliance on resource-intensive workaroundsto modify a data set for plotting within the range of values of thetheta axis.

As indicated above, FIG. 14 is provided merely as an example. Otherexamples are possible and may differ from what was described with regardto FIG. 14. For example, client device 210 is described as performingoperations in connection with FIG. 14. In some implementations, one ormore other devices, such as one or more server devices 230, may performone or more of these operations independent of or in combination withclient device 210.

FIG. 15 is a diagram of an example implementation of rendering agraphical scene, including a specified location of an r-axis, based onapplication programming interface instructions.

As shown in FIG. 15, and by reference number 1510, client device 210(e.g., TCE 220) may receive an API instruction to render a graphicalscene that includes a polar plot (e.g., “polarplot(th, r)”). Based onthe API instruction to render the graphical scene, client device 210 maygenerate an object tree in a polar coordinate system, as described inmore detail elsewhere herein, such as in connection with FIGS. 8B and11F.

As shown by reference number 1520, client device 210 (e.g., TCE 220) mayreceive an API instruction to modify a displayed location of the r-axis(e.g., “set(gca, ‘ThetaZeroLocation’, ‘45’”). Here, the API instructionspecifies the property of “ThetaZeroLocation” and a value to assign tothe property (e.g., a value of “45,” indicating to place the R-axis at a45-degree rotation in the graphical scene), as shown by reference number1530. As shown by reference number 1540, client device 210 may provide,for display, the polar plot. As shown, the polar plot may include aR-axis that is displayed in a rotated position. Assume that clientdevice 210 modifies the “ThetaZeroLocation” property of an object of theobject tree, and generates the polar plot based on the object tree.

In this way, client device 210 and/or TCE 220 may generate the graphicalscene according to a specified position of the r-axis, which improvesreadability and/or versatility of the graphical scene and/or conservesprocessing resources by reducing user reliance on resource-intensiveworkarounds to customize the graphical scene.

As indicated above, FIG. 15 is provided merely as an example. Otherexamples are possible and may differ from what was described with regardto FIG. 15. For example, client device 210 is described as performingoperations in connection with FIG. 15. In some implementations, one ormore other devices, such as one or more server devices 230, may performone or more of these operations independent of or in combination withclient device 210.

FIG. 16 is a flow chart of an example process 1600 for generating and/ormodifying a graphical scene based on input. In some implementations, oneof more process blocks of FIG. 16 may be performed by client device 210.In some implementations, one or more process blocks of FIG. 16 may beperformed by another device or a set of devices separate from orincluding client device 210, such as server device 230. In someimplementations, one or more process blocks of FIG. 16 may be performedby one or more TCEs 220 executing on client device 210 and/or serverdevice 230.

As shown in FIG. 16, process 1600 may include receiving input related toa graphical scene (block 1610). For example, client device 210 (e.g.,TCE 220) may receive an input (e.g., via TCE 220). The input may relateto a graphical scene. For example, the input may include an APIinstruction related to generating and/or modifying a graphical sceneand/or an object tree of a graphical scene. In some implementations, theinput may include data that is expressed in a non-Cartesian coordinatesystem. For example, the input may include data that is expressed in apolar data system. In some implementations, the input may include an APIinstruction to specify one or more objects, of the object tree, tomodify, as described in more detail in connection with block 610 of FIG.6, above.

In some implementations, the input may relate to modifying a renderedgraphical scene. For example, client device 210 may receive an APIinstruction related to an existing graphical scene and/or object tree,as shown in FIGS. 11B and 11E and elsewhere herein. In such cases,client device 210 may modify one or more objects of the existing objecttree, as described in more detail in connection with FIG. 21, below.

As further shown in FIG. 16, process 1600 may include determining, basedon an indicator received in association with the input, that thegraphical scene relates to a polar coordinate system (block 1620). Forexample, the input may include an indicator that indicates that theinput and/or the graphical scene relates to a polar coordinate system.Client device 210 (e.g., TCE 220) may determine that the API instructionis related to a polar coordinate system based on syntax of the APIinstruction. As an example, an API instruction to generate a plot, ahistogram, an area, a scatter chart, or a contour plot, based on dataexpressed in a Cartesian coordinate system, may include “plot(y),”“histogram(y),” “area(y),” “scatter(y),” and “contour(y),” respectively.An API instruction to generate a plot in a polar coordinate system mayinclude an indicator that indicates that the input is related to thepolar coordinate system. For example, the API instruction may include“polarplot(r),” “polarhistogram(y),” “polararea(y),” “polarscatter(y),”“polarcontour(y),” and so on. Client device 210 may selectively generatean object tree in the Cartesian coordinate system, or the polarcoordinate system, based on whether client device 210 detects the“polar” indicator in association with the API instruction.

In some implementations, client device 210 (e.g., TCE 220) may determinethat an API instruction relates to a polar coordinate system based on asyntax of the API instruction. Example implementations of APIinstructions relating to a polar coordinate system are shown in exampletable 3, below:

TABLE 3 API instruction Action ax = axes; Obtains a handle to a[Theta/R]-axis [Theta/R]_ruler handle = object. ax.[Theta/R]Axis ax =gca; Selects axes object for most recently generated or selected axisfor modification ax.[Theta/R]Axis.[Property] = Sets a value of aproperty relating to the (arg) [Theta/R]-axis to the value specified in(arg) set(gca, ‘[Property]’, ‘(arg)’) Sets a value of a property of anobject relating to the most recently generated or selected axis of agraphical scene.

API instructions shown in example table 3 may specify which axis, of atheta-axis and an r-axis, to modify. For example, the API instruction[Theta/R]_ruler_handle=ax.[Theta/R]Axis may includeTheta_ruler_handle=ax.ThetaAxis when related to the theta-axis, and mayinclude R_ruler_handle=ax.RAxis when related to the r-axis. In someimplementations, API instructions shown in example table 3 may includeadditional characters, fewer characters, and/or different characters.Additionally, or alternatively, API instructions may be associated withadditional actions, fewer actions, different actions, additionalarguments, fewer arguments, and/or different arguments.

In some implementations, an API instruction may identify a property tomodify. Example implementations of properties and values that may beassociated with the properties are shown in example table 4 below:

TABLE 4 Property/object Values ThetaZeroLocation Location of zero-valueof theta-axis; values include ‘left’, ‘right’, ‘top’, bottom’.ThetaAxisUnits Numerical format for theta-axis tick values; valuesinclude ‘degrees’]and‘radians’ RAxisLocation Location of the r-axis;values include ‘degrees’]and‘radians’, in the unit of ThetaAxisUnits.[Theta/R]MinorTick Toggle minor tick marks on the specified axis; valuesinclude on and off. [Theta/R]Scale Specify a scale of the specifiedaxis; values include linear and log. [Theta/R]Tick Specify tick marklocations on the specified axis; values include auto and/or a vector ofvalues (e.g., [2 4 6], 0:10:100, etc.). [Theta/R]TickLabel Specify tickmark labels for the specified axis; values include an array of strings(e.g., [NE W S], etc.) [Theta/R]TickLabelRotation Specify tick marklabel orientation angle for the specified axis; values include a scalarvalue in degrees or radians. [Theta/R]Color Specify color of outline andtick marks for the specified axis; values include strings (e.g.,‘yellow’, ‘cyan’, etc.). [Theta/R]Dir Specify direction of increasingvalues along the specified axis; values include ‘counterclockwise’ and‘clockwise’'. [Theta/R]Label Specify text for a label of the specifiedaxis; values include strings. [Theta/R]Lim Specify minimum and maximumaxis limits for the specified axis; values include a two-element vectorof the form [min max]. [Theta/R]Grid Specify whether to display a gridin relation to the specified axis; values include on and off.[Theta/R]MinorGrid Specify whether to display a minor grid in relationto the specified axis; values include on and off.

When a property in example table 4 is preceded by [Theta/R], an APIinstruction that calls the property may include “Theta” or “R” to causeclient device 210 (e.g., TCE 220) to modify the property with regard tothe theta-axis or the r-axis, respectively. For example, to modify acolor of the theta-axis, a user may input “ThetaColor(‘red’),” and tomodify a color of the r-axis, a user may input “RColor(‘red’).” In someimplementations, API instructions may include additional characters,fewer characters, and/or different characters. Additionally, oralternatively, API instructions may be associated with additionalactions, fewer actions, different actions, additional arguments, fewerarguments, and/or different arguments.

As further shown in FIG. 16, process 1600 may include generating, basedon the input and based on determining that the graphical scene relatesto the polar coordinate system, an object tree that performs operationsin the polar coordinate system (block 1630). For example, client device210 (e.g., TCE 220) may determine that the input relates to the polarcoordinate system. Accordingly, client device 210 may generate an objecttree that performs operations in the polar coordinate system. An objecttree that performs operations in the polar coordinate system may bereferred to herein as a polar object tree.

As further shown in FIG. 16, process 1600 may include storing and/orproviding the object tree (block 1640). For example, client device 210(e.g., TCE 220) may store the object tree. In some implementations,client device 210 may provide the object tree to another device (e.g.,server device 230, etc.) for the other device to store. In someimplementations, client device 210 may provide the object tree fordisplay. For example, client device 210 may provide the object tree fordisplay via TCE 220, and/or may provide properties of objects fordisplay.

As further shown in FIG. 16, process 1600 may include rendering agraphical scene based on the object tree (block 1650). For example,client device 210 (e.g., TCE 220) may render a graphical scene based onthe object tree. In some implementations, another device may render thegraphical scene (e.g., server device 230, etc.). In someimplementations, client device 210 may generate a graphical renderingtree based on the object tree, as described in more detail in connectionwith block 640 of FIG. 6, above. In such implementations, client device210, or another device, may render the graphical scene based on thegraphical rendering tree.

As further shown in FIG. 16, process 1600 may include providing thegraphical scene (block 1660). For example, client device 210 (e.g., TCE220) may provide the graphical scene. In some implementations, clientdevice 210 may provide the graphical scene for display (e.g., via TCE220). In some implementations, client device 210 may provide informationdescribing the graphical scene to another device (e.g., server device230, etc.) for storage and/or processing. In this way, client device 210may render and/or provide a graphical scene based on a polar objecttree. Client device 210 may generate the polar object tree based on aCartesian object tree, which improves efficiency of generating the polarobject tree and/or rendering the graphical scene, and which improvesuniformity and/or predictability of API instructions of polar objecttrees and Cartesian object trees.

Although FIG. 16 shows example blocks of process 1600, in someimplementations, process 1600 may include additional blocks, fewerblocks, different blocks, or differently arranged blocks than thosedepicted in FIG. 16. Additionally, or alternatively, two or more of theblocks of FIG. 16 may be performed in parallel.

FIGS. 17A and 17B are diagrams of an example implementation ofgenerating and modifying an object tree including a ruler object, andrendering graphical scenes, based on application programming interfaceinstructions.

As shown in FIG. 17A, and by reference number 1710, client device 210(e.g., TCE 220) may receive an API instruction to generate a plot, in aCartesian coordinate system, based on a data set (e.g., plot(x,y)).Based on the API instruction, client device 210 may generate an objecttree, as described in more detail in connection with FIG. 17B. As shownby reference number 1720, client device 210 may generate the plot basedon the data set. As shown by reference number 1730, an x-axis of theplot may be placed at a bottom of the plot, and may intersect a y-axisat a y-value of −0.6. As shown by reference number 1740, the plotteddata set may converge to a y-value of 0 as the x-value increases.

As shown by reference number 1750, client device 210 (e.g., TCE 220) mayreceive API instructions to specify locations of the x-axis and they-axis (e.g., “set(gca, ‘XAxisLocation’, ‘origin’); set(gca,‘YAxisLocation’, ‘origin’”). As shown, the API instructions may specifyan object to modify (e.g., “gca,” which may specify the most recentlygenerated or selected axis object), properties of the object to modify(e.g., “XAxisLocation” and “YAxisLocation”), and values to assign to theproperties (e.g., “origin”). The property of “origin” may cause clientdevice 210 to display the x-axis and the y-axis as crossing at an originof the plot, as shown by reference number 1760.

FIG. 17B shows an object tree which may be generated and/or modifiedbased on the API instructions received in connection with FIG. 17A. Asshown, the object tree may include a dataspace, which may be connectedwith (e.g., capable of modifying) an XAxis object, a YAxis object, and adata object. The data object may store properties related to plotteddata sets (e.g., x, y, etc.). As shown, the XAxis object and the YAxisobject may be associated with respective ruler objects. The rulerobjects may store properties related to labels, tick marks, positioning,and/or formatting of the respective axes.

As shown by reference number 1770, the object may store propertiesidentifying the ruler objects (e.g., “X Ruler object: XAxis/Ruler” and“Y Ruler object: YAxis/Ruler”). When client device 210 (e.g., TCE 220)receives an API instruction to modify a property stored by a rulerobject, client device 210 may determine the appropriate ruler objectbased on the property of the object that identifies the ruler object.For example, when client device 210 receives an API instruction tomodify a ruler object property for the x-axis, client device 210 maydetermine a ruler object of an XAxis object based on the property storedby the object.

As shown by reference number 1780, the ruler object of the XAxis objectmay store a property (e.g., “XAxisLocation”) defining a location atwhich to display the x-axis (e.g., “origin,” indicating to display thex-axis crossing the origin of the plot). As shown by reference number1790, the ruler object of the YAxis object may store a property (e.g.,“YAxisLocation”) defining a location at which to display the y-axis(e.g., “origin,” indicating to display the y-axis crossing the origin ofthe plot). In this way, client device 210 (e.g., TCE 220) may modifyproperties of the ruler object, which may permit a user to specifymodifications for properties of displayed axes in the object tree. Bypermitting the user to cause modification of the properties, clientdevice 210 reduces reliance on inefficient, slow, and/orresource-intensive workarounds to achieve similar results, whichimproves performance and reduces processor resource consumption.

As indicated above, FIGS. 17A and 17B are provided merely as an example.Other examples are possible and may differ from what was described withregard to FIGS. 17A and 17B. For example, client device 210 is describedas performing operations in connection with FIGS. 17A and 17B. In someimplementations, one or more other devices, such as one or more serverdevices 230, may perform one or more of these operations independent ofor in combination with client device 210.

FIGS. 18A and 18B are diagrams of an example implementation ofgenerating and modifying an object tree including a ruler object, andrendering graphical scenes, based on application programming interfaceinstructions. For the purpose of FIGS. 18A and 18B, assume that clientdevice 210 generates an object tree, as shown in FIG. 18B, and thatclient device 210 renders a graphical scene based on the object tree.

As shown in FIG. 18A, client device 210 (e.g., TCE 220) may receive anAPI interaction to select the object tree for modification (e.g.,“ax=gca”). As shown by reference number 1810, client device 210 mayreceive an API instruction to specify an exponent, based on which todetermine tick mark labels of the y-axis (e.g., “set(ax.YAxis,‘Exponent’,9);”). Based on the API instruction, client device 210 maymodify an “Exponent” property of the object tree, as described in moredetail in connection with FIG. 18B. As shown by reference number 1820,client device 210 may re-render the plot based on the modified object.As shown, the y-axes of the plots of “Samoa” and “Sweden” display valuesin scientific notation, with an exponent of 9.

FIG. 18B shows an object tree which is modified based on the APIinstructions received in connection with FIG. 18A. As shown, the objecttree may include a dataspace, which may be connected with an XAxisobject, a YAxis object, and a data object. As shown, the XAxis objectand the y-axis object may be associated with ruler objects.

As shown by reference number 1830, the ruler object of the YAxis objectmay store a property (e.g., “Exponent”). As shown, the Exponent propertymay store a value defining an exponent, based on which to determinelabels of the corresponding axis (e.g., “9,” indicating to calculatetick mark labels of the y-axis in scientific notation, with an exponentvalue of 9). In some implementations, an object may store a property(e.g., an ExponentMode property, etc.), that may store values such as“manual” and “auto,” indicating whether to use a property value of“Exponent” or to use a predefined rule to calculate tick mark labelsand/or exponent values. Client device 210 (e.g., TCE 220) may modify theExponent property of the ruler object based on the Axes objectidentifying the ruler object.

In this way, client device 210 (e.g., TCE 220) may modify properties ofthe ruler object, which may permit a user to specify modifications forproperties of displayed axes in the object tree. By permitting the userto specify modification of the properties, client device 210 reducesreliance on inefficient, slow, and resource-intensive workarounds toachieve similar results, which improves performance and reducesprocessor resource consumption.

As indicated above, FIGS. 18A and 18B are provided merely as an example.Other examples are possible and may differ from what was described withregard to FIGS. 18A and 18B. For example, client device 210 is describedas performing operations in connection with FIGS. 18A and 18B. In someimplementations, one or more other devices, such as one or more serverdevices 230, may perform one or more of these operations independent ofor in combination with client device 210.

FIG. 19 is a diagram of an example implementation of modifying agraphical scene based on application programming interface instructions.

As shown in FIG. 19, client device 210 (e.g., TCE 220) may receive anAPI instruction to plot a value (e.g., plot(pi), to plot a value of themathematical constant of pi). As shown by reference number 1910, clientdevice 210 may render and provide, for display, a graphical sceneincluding plot of the value of pi. Here, the y-axis displays values at afirst, lowest, level of granularity (e.g., lowest as compared to anintermediate level and a highest level). As shown by reference number1920, client device 210 may receive an interaction (e.g., an APIinstruction, a mouse click, a mouse drag, etc.) to magnify a portion ofthe plot (e.g., “zoom in,” and a rectangle indicating the portion).

As shown by reference number 1930, based on the API instruction 1920 tomagnify the portion, client device 210 may modify the y-axis. Here,client device 210 (e.g., TCE 220) modifies the y-axis to display tickmark labels at a second, intermediate level of granularity. As shown,the modified y-axis displays tick mark labels of 2.9, 3.0, 3.1, and 3.2.As shown by reference number 1940, client device 210 may receive anotherAPI instruction to magnify a portion of the plot (e.g., “zoom in,” and arectangle indicating a portion smaller than the portion indicated inassociation with reference number 1920).

As shown by reference number 1950, based on the other API instruction tomagnify, client device 210 (e.g., TCE 220) may modify the y-axis. Here,client device 210 modifies the y-axis to display values at a third,highest level of granularity. Client device 210 may modify objectsrelated to the y-axis based on the specified portion of reference number1940. For example, the object tree may modify a Limits property of aruler object, to identify the range of values included between3.141592653589792 and 3.141592653589798.

Client device 210 (e.g., TCE 220) may determine displayed tick marklabels based on the third, highest level of granularity. For example,client device 210 may determine that a first decimal digit through afourteenth decimal digit of the upper limit of the y-axis are equal to afirst decimal digit through a fourteenth decimal digit of the lowerlimit of the y-axis. Client device 210 may determine that a fifteenthdecimal digit of the upper limit of the y-axis is not equal to afifteenth decimal digit of the lower limit of the y-axis, and mayaccordingly display fifteen decimal digits in the tick mark labels ofthe y-axis. In this way, client device 210 may automatically determinetick mark labels of axes, which conserves processor resources that mayotherwise be used for a user to input the tick mark labels.

As indicated above, FIG. 19 is provided merely as an example. Otherexamples are possible and may differ from what was described with regardto FIG. 19. For example, client device 210 is described as performingoperations in connection with FIG. 19. In some implementations, one ormore other devices, such as one or more server devices 230, may performone or more of these operations independent of or in combination withclient device 210.

FIGS. 20A-20D are diagrams of an example implementation 2000 ofgenerating and modifying axes of graphical scenes based on applicationprogramming interface instructions and based on a generated object tree.

As shown in FIG. 20A, client device 210 (e.g., TCE 220) may receive APIinstructions related to generating axes for a plot. As shown, clientdevice 210 may receive a first API instruction of “ax=axes;”. Based onthe first API instruction, client device 210 may generate an object treethat includes one or more ruler objects, as described in connection withFIG. 20D. For example, client device 210 may generate an object of theobject tree (e.g., an Axes object), and the Axes object may generate aset of objects for the object tree. As shown, client device 210 mayreceive a second API instruction of “XLim([−1 1]);” and a third APIinstruction of “YLim([−1 1]);.” Based on the second API instruction andthe third API instruction, client device 210 (e.g., the parent Axesobject) may generate ruler objects, and may assign properties of theruler objects to define a lower limit of the x-axis and the y-axis as−1, and to define an upper limit of the x-axis and the y-axis as 1. Asfurther shown, client device 210 may receive a fourth API instructionand a fifth API instruction to cause client device 210 to place thex-axis and the y-axis at the origin of the plot (e.g.,“ax.YAxisLocation=‘origin’;” and “ax.XAxisLocation=‘origin’;”). Asshown, client device 210 may receive a sixth API interaction to causeclient device 210 to include a box enclosing the plot (e.g., “box on”).

As further shown, based on the six API interactions, client device 210(e.g., TCE 220) may render a graphical scene including the plot, and mayprovide the graphical scene and the plot for display. As shown, thex-axis and the y-axis cross at the origin of the plot, and the x-axisand the y-axis span from a value of −1 to a value of 1.

As shown in FIG. 20B, and by reference number 2005, client device 210(e.g., TCE 220) may receive an API instruction to cause client device210 to modify upper limits, lower limits, and/or displayed locations ofthe x-axis and/or the y-axis (e.g., “pan upward”). As shown, based onthe API instruction, client device 210 may modify the plot, and mayprovide the modified plot for display. Assume that client device 210modifies objects, of the object tree shown in FIG. 20D, based on the APIinstruction (e.g., a Limits value of Ruler objects associated with thex-axis and/or the y-axis, etc.). As shown, the plot, as modified,includes a range of x-values between roughly −6×10⁷ and roughly 12×10⁷,and a range of y-values between roughly 0.6×10⁸ and roughly 2.6×10⁸.

As shown by reference number 2010, client device 210 (e.g., TCE 220) mayprovide, for display, a label in association with the y-axis (e.g.,“ylabel”). In some implementations, client device 210 may display thelabel in a particular location based on a rule. Here, client device 210displays the label in a smaller portion of the plot (e.g., in thesmaller portion to the left of the y-axis, as compared to the largerportion to the right of the y-axis). In this case, the rule may causeclient device 210 to display the label in the smaller portion of theplot. As another example, a rule may cause client device 210 to displaythe label in a location that does not overlap a displayed data set. Forexample, in the displayed plot, if a displayed data set includes a valuethat is displayed at y=1.6, client device 210 may display the label at adifferent location than the location shown by reference number 2010,such as north of that location, south of that location, or the like. Inthis way, client device 210 may determine a location at which to displaya label of the y-axis based on a rule, which reduces processor resourceusage that may otherwise be used in connection with API instructions tospecify a location of the label.

As yet another example, client device 210 (e.g., TCE 220) may displaythe label in a specified location (e.g., specified by a user). Forexample, a user may specify a particular y-value and/or a portion of theplot in which to display the label. In this way, client device 210 maydetermine a location at which to display a label of the y-axis based ona user input, which improves readability of the plot.

As shown by reference number 2015, client device 210 (e.g., TCE 220) mayprovide, for display, a label in association with the x-axis (e.g.,“xlabel”). In some implementations, client device 210 may display thelabel in particular location based on a rule. Here, client device 210displays the label below the x-axis and in a central location. In thiscase, the rule may cause client device 210 to display the label belowthe x-axis and in the central location when the displayed label will notoverlap with other plot elements in the central location. In this way,client device 210 may determine a location at which to display a labelof the x-axis based on a rule, which may reduce processor resource usagethat may otherwise be used in association with API instructions tospecify a location of the label. In some implementations, client device210 may receive an input (e.g., an API interaction, etc.) to specify alocation at which to display the label, which improves readability ofthe plot.

As shown by reference number 2020, client device 210 (e.g., TCE 220) maydetermine a first exponent, based on which to display tick mark labelsof the x-axis in scientific notation. Here, the first exponent is 7, andthe displayed tick mark labels of the x-axis are −6, −4, −2, and so on(e.g., corresponding to values of −60,000,000, −40,000,000, −20,000,000,and so on, based on the first exponent of 7). As shown by referencenumber 2025, client device 210 may determine a second exponent, based onwhich to display tick mark labels of the y-axis. Here, the secondexponent is 8, and the displayed tick mark labels are 0.8, 1, 1.2, andso on (e.g., corresponding to values of 80,000,000, 100,000,000,120,000,000, and so on, based on the exponent of 8).

In some implementations, client device 210 (e.g., TCE 220) may selectthe first exponent and/or the second exponent based on a rule. Forexample, the rule may cause client device 210 to select the firstexponent and/or the second exponent to cause a particular quantity ofdigits to be displayed in tick mark labels of the corresponding axis(e.g., one digit to the left of the decimal, three digits to the left ofthe decimal, a specified quantity of digits to the left of the decimal,a particular quantity of digits to the right of the decimal, etc.). Asanother example, the rule may cause client device 210 to select theexponent from a particular set of exponents (e.g., in engineeringnotation, wherein the exponent may be selected from a set of multiplesof three, etc.). In this way, client device 210 may select the firstexponent and/or the second exponent based on a rule, which conservesprocessor resources that may otherwise be used for API instructions tospecify the first exponent and/or the second exponent.

As shown by reference numbers 2020 and 2025, client device 210 (e.g.,TCE 220) may display information related to the exponent. Here, clientdevice 210 displays information related to a scale of the tick marklabels (e.g., “×10⁷” and “×10⁸,” respectively, denoting that the tickmark labels of the x-axis and the y-axis are displayed in scientificnotation). In some implementations, client device 210 may display theinformation related to the exponent in a particular location based on arule. For example, client device 210 may place the information to avoidoverlap of the information and a displayed data set, may place theinformation on a particular side of a particular axis (e.g., below orabove the x-axis, to the right of or to the left of the y-axis, etc.),may place the information in a particular portion of the plot (e.g., ina larger portion of the plot, in a smaller portion of the plot, etc.),or the like. In this way, client device 210 may select the particularlocation based on a rule, which conserves processor resources that mayotherwise be used for API instructions to specify the particularlocation.

As shown in FIG. 20C, and by reference number 2030, client device 210(e.g., TCE 220) may receive API instructions to modify upper limits,lower limits, and/or locations of the x-axis and/or the y-axis (e.g.,“pan downward” and “pan left”). As shown, based on the API instructions,client device 210 may re-render the plot, and may provide the plot fordisplay via TCE 220. Assume that client device 210 modifies objects, ofthe object tree shown in FIG. 20D, based on the API instruction (e.g., aLimits property of an object, etc.). As shown, the plot, as modified,includes a range of displayed x-values between roughly −14×10⁷ androughly 6×10⁷, and a range of y-values between roughly −4×10⁷ androughly 14×10⁷.

As shown by reference numbers 2035 and 2040, client device 210 (e.g.,TCE 220) may determine a first exponent and a second exponent, based onwhich to display tick mark labels of the x-axis and the y-axis inscientific notation. Here, the first exponent is 7, and is unchangedfrom the first exponent of FIG. 20B. As shown, the second exponent inFIG. 20C is 7, as compared to the value of the second exponent of 8 asshown in FIG. 20B. Client device 210 may modify the first exponentand/or the second exponent based on a rule, based on an input, or thelike. For example, here, client device 210 may modify the value of thesecond exponent to cause a particular quantity of digits to be displayedin tick mark labels of the y-axis, or the like.

As shown by reference numbers 2045 and 2050, client device 210 (e.g.,TCE 220) may place a label relating to the x-axis (e.g., xlabel) and alabel relating to the y-axis (e.g., ylabel) in particular locations.Client device 210 may select the particular locations based on amidpoint of a longer portion of the corresponding axis. For example, asshown by reference number 2045, client device 210 places “xlabel” at amidpoint of a longer portion of the x-axis (e.g., the portion to theleft of the y-axis, which is longer than the portion to the right of they-axis). As another example, as shown by reference number 2050, clientdevice 210 places “ylabel” at a midpoint of a longer portion of they-axis (e.g., the portion above the x-axis, which is longer than theportion below the x-axis). In this way, client device 210 may place thelabels according to a rule, which conserves processor power by reducinga quantity of API instructions received in relation to placement of thelabels.

As shown in FIG. 20D, client device 210 (e.g., TCE 220) may generateand/or modify an object tree based on API instructions received, forexample, in FIGS. 20A-20C. As further shown, the object tree includes anobject, a dataspace, and a set of objects. As shown, the XAxis propertyand the Yaxis object are stored by respective ruler objects. Here, asshown by reference number 2055, the ruler object of the x-axis and theruler object of the y-axis may store an XaxisLocation property and aYaxisLocation property, respectively, that may be related to displayedpositions of the x-axis and the y-axis (e.g., the properties may include“Origin,” indicating to display the x-axis and the y-axis as crossingthe origin of the plot).

As shown by reference number 2060, the ruler object of the x-axis andthe ruler object of the y-axis may store ExponentMode properties thatwhether to automatically determine values of the exponents shown inFIGS. 20A-20C. As shown, the ExponentMode properties may be associatedwith values of “Auto,” indicating to determine the values of theexponents automatically (e.g., based on a rule, etc.). In someimplementations, the Exponent objects may store a value indicating ofuse a user-specified value of the first exponent and/or the secondexponent (e.g., “Manual,” etc.), may store a value identifying the firstexponent and/or the second exponent, or the like.

As shown by reference number 2065, the ruler object of the x-axis maystore a Limits property that is associated with a value of [−1600000040000000]. The value of the Limits property may identify a lower limitand an upper limit of the x-axis shown in FIG. 20C. As shown byreference number 2070, the ruler object of the y-axis may store a Limitsproperty that is associated with a value of [−50000000 140000000], whichmay identify a lower limit and an upper limit of the y-axis, as shown inFIG. 20C. In some implementations, the properties may be determinedbased on the API instructions shown in FIGS. 20A-20C.

As indicated above, FIGS. 20A-20D are provided merely as an example.Other examples are possible and may differ from what was described withregard to FIGS. 20A-20D. For example, client device 210 is described asperforming operations in connection with FIGS. 20A-20D. In someimplementations, one or more other devices, such as one or more serverdevices 230, may perform one or more of these operations independent ofor in combination with client device 210.

FIG. 21 is a flow chart of an example process 2100 for generating and/ormodifying an object of an object tree based on a user input. In someimplementations, one of more process blocks of FIG. 21 may be performedby client device 210. In some implementations, one or more processblocks of FIG. 21 may be performed by another device or a set of devicesseparate from or including client device 210, such as server device 230.In some implementations, one or more process blocks of FIG. 21 may beperformed by one or more TCEs 220 executing on client device 210 and/orserver device 230.

As shown in FIG. 21, process 2100 may include receiving user inputrelated to modifying an object of an object tree (block 2110). Forexample, client device 210 (e.g., TCE 220) may receive user inputregarding a graphical scene. The graphical scene may be rendered basedon an object tree. The object tree may include one or more objects, andthe user input may relate to modifying one or more objects. Clientdevice 210 may determine a subset of the one or more objects to modify,and may determine properties, of the one or more objects, to modifybased on the user input.

In some implementations, the user input may identify the object. Forexample, as shown in FIG. 18A, and by reference number 1810, the userinput may identify the object to be modified and/or one or more otherobjects connected to the object. As shown by reference number 1810, theuser input identifies a yaxis object, of the object tree shown in FIG.18B, and identifies an Exponent object that is connected to the yaxisobject. As another example, reference number 1750 of FIG. 17A shows auser input that identifies two properties (e.g., ‘XAxisLocation’ and‘YAxisLocation’) of an object, to modify, and a value to assign to thoseproperties (e.g., ‘origin’).

In some implementations, client device 210 (e.g., TCE 220) may determinethe object based on the user input. For example, the user input may notspecify the object, as shown, for example, in FIG. 19. In such cases,client device 210 may, for example, determine the object based onmodifications required to perform an action specified in the user input.For example, in FIG. 19, the user input specifies to “zoom in.” Based onthe user input specifying to “zoom in,” client device 210 may determineto modify objects related to an upper limit, a lower limit, tick marks,and/or tick mark labels of the x-axis and/or the y-axis.

When an API instruction relates to modifying a ruler object, the APIinstruction may cause client device 210 (e.g., TCE 220) to assign ormodify a value of a property of the ruler object. For example, the APIinstruction may be an API instruction shown in example table 1 of FIG. 6and/or example table 3 of FIG. 16, and the API instruction may specify aproperty of a ruler object and a value for the property. Exampleimplementations of properties of ruler objects and values of theproperties are shown in example table 5, below:

TABLE 5 Property Value Exponent Control scaling of numeric tick valuesof the ruler; values include integers for use as an exponent to scalethe numeric tick values MinorTick Values Specify values at which toplace minor tick marks; values include a double precision number arrayMinorTickValuesMode Specify whether to determine minor tick valuesautomatically or based on user input; values include ‘auto’ and‘manual’. TickLabelFormat Specify formatting for tick labels of theruler; values includea string, as described in more detail below.MinorTick Toggle minor tick marks on the active axis; values include onand off. Scale Specify a scale of the active axis; values include linearand log. Tick Values Specify tick mark locations on the active axis;values include auto and a vector of values (e.g., [2 4 6],0:10:100,etc.). TickLabel Specify tick mark labels for the active axis;values include an array of strings (e.g., [NE W S], etc.)TickLabelRotation Specify tick mark label orientation (e.g., rotation)angle for the active axis; values include a scalar value in degrees orradians. Color Specify color of outline and tick marks for the activeaxis; values include strings (e.g., ‘yellow’, ‘cyan’, etc.). DirectionSpecify direction of increasing values along active axis; values include‘normal’ and ‘reverse’. Label Specify text for a label of the activeaxis; values include strings. Limits Specify minimum and maximum axislimits for the active axis; values include a two-element vector of theform [min max]. LimitsMode Specify method of determining minimum andmaximum axis limits for the active axis; values include ‘auto’ and‘default’

In some implementations, the properties and/or values may includeadditional characters, fewer characters, and/or different characters.Additionally, or alternatively, the properties may be associated withadditional actions, fewer actions, different actions, additional values,fewer values, and/or different values.

As further shown in FIG. 21, process 2100 may include modifying theobject based on the user input (block 2120). For example, client device210 (e.g., TCE 220) may modify the object based on the user input. Insome implementations, client device 210 may modify a property, of anobject, based on the user input. For example, the user input may specifya value of the property, and client device 210 may modify the propertyaccordingly. In some implementations, client device 210 may generate anobject based on the user input (e.g., when the object identified by theuser input does not already exist), and may assign a value of a propertyidentified by the user input to the object.

Based on modifying the object, client device 210 (e.g., TCE 220) may seta value of a flag associated with the object and/or one or more otherobjects. For example, as described in connection with FIGS. 5C-5E, anobject tree may include a group of flags that may be connected to agroup of respective objects of the object tree. When client device 210modifies an object, client device 210 may set a value of a respectiveflag that is connected to the modified object. In cases where themodification to the object leads to modifications to other objects,client device 210 may set values of respective flags that are connectedto the other objects. Based on the flags, client device 210 may modify agraphical rendering tree that relates to the object tree, as describedin more detail elsewhere herein.

In some implementations, client device 210 (e.g., TCE 220) may receive auser input related to a ruler object. For example, the object tree mayinclude a ruler object that stores properties related to displaying,configuring, and/or modifying axis rulers. The user input may identifyand/or relate to a property of the ruler object, or of an objectconnected to the ruler object, as described, for example, in connectionwith FIGS. 17A, 18A, 19A, and 20A-C. Additionally, or alternatively,client device 210 may receive a user input related to a polar coordinatesystem. For example, a polar object tree may include objects that storeproperties and/or perform operations related to a polar coordinatesystem. The user input may identify and/or relate to a property of anobject of the polar object tree, as described, for example, inconnection with FIGS. 8A, 9A, 10A, 11A-11E, 12, 13A, 14, and 15.

As further shown in FIG. 21, process 2100 may include rendering agraphical scene based on the object tree (block 2130). For example,client device 210 (e.g., TCE 220) may render a graphical scene based onthe object tree. The graphical scene may differ from a previouslyrendered graphical scene based on the user input. For example, thegraphical scene may include one or more elements that are modified basedon the user input, as compared to one or more elements of the previouslyrendered graphical scene. In some implementations, client device 210 mayrender the graphical scene based on a graphical rendering tree, asdescribed in more detail elsewhere herein.

As further shown in FIG. 21, process 2100 may include providing, fordisplay, the graphical scene (block 2140). For example, client device210 (e.g., TCE 220) may provide the graphical scene for display. In someimplementations, server device 230 may render the graphical scene, andmay provide the rendered graphical scene for display via TCE 220, hostedby client device 210. In this way, client device 210 and/or serverdevice 230 may render a graphical scene based on a modified object tree.The object tree may facilitate customization of the graphical scene,which reduces a quantity of API interactions required to customize thegraphical scene and, thus, reduces processor resource requirements.

Although FIG. 21 shows example blocks of process 2100, in someimplementations, process 2100 may include additional blocks, fewerblocks, different blocks, or differently arranged blocks than thosedepicted in FIG. 21. Additionally, or alternatively, two or more of theblocks of FIG. 21 may be performed in parallel.

The foregoing disclosure provides illustration and description, but isnot intended to be exhaustive or to limit the implementations to theprecise form disclosed. Modifications and variations are possible inlight of the above disclosure or may be acquired from practice of theimplementations.

As used herein, the term component is intended to be broadly construedas hardware, firmware, and/or a combination of hardware and software.

Program code (sometimes referred to herein as code) is to be broadlyinterpreted to include text-based code that may not require furtherprocessing to execute (e.g., C++ code, Hardware Description Language(HDL) code, very-high-speed integrated circuits (VHSIC) HDL (VHDL) code,Verilog code, Java code, another type of hardware and/or software basedcode that may be compiled and/or synthesized, etc.), binary code thatmay be executed (e.g., executable files that may be directly executed byan operating system, bitstream files that may be used to configure anFPGA, Java byte code, object files combined together with linkerdirectives, source code, makefiles, etc.), text files that may beexecuted in conjunction with other executables (e.g., Python text files,Octave files, a collection of dynamic-link library (DLL) files withtext-based combining, configuration information that connectspre-compiled modules, an extensible markup language (XML) filedescribing module linkage, etc.), source code (e.g., readable by ahuman), machine code (e.g., readable by a machine), or the like. In someimplementations, program code may include different combinations of theabove-identified classes of code (e.g., text-based code, binary code,text files, source code, machine code, etc.). Additionally, oralternatively, program code may include code generated using adynamically-typed programming language (e.g., the M language, a MATLAB®language, a MATLAB-compatible language, a MATLAB-like language, etc.)that may be used to express problems and/or solutions using mathematicalnotations. Additionally, or alternatively, program code may be of anytype, such as a function, a script, an object, etc.

Certain user interfaces have been described herein and/or shown in thefigures. A user interface may include a graphical user interface, anon-graphical user interface, a text-based user interface, etc. A userinterface may provide information for display. In some implementations,a user may interact with the information, such as by providing input viaan input component of a device that provides the user interface fordisplay. In some implementations, a user interface may be configurableby a device and/or a user (e.g., a user may change the size of the userinterface, information provided via the user interface, a position ofinformation provided via the user interface, etc.). Additionally, oralternatively, a user interface may be pre-configured to a standardconfiguration, a specific configuration based on a type of device onwhich the user interface is displayed, and/or a set of configurationsbased on capabilities and/or specifications associated with a device onwhich the user interface is displayed.

It will be apparent that systems and/or methods, described herein, maybe implemented in different forms of hardware, firmware, or acombination of hardware and software. The actual specialized hardware orsoftware code used to implement these systems and/or methods is notlimiting of the implementations. Thus, the operation and behavior of thesystems and/or methods were described herein without reference tospecific software code—it being understood that software and hardwarecan be designed to implement the systems and/or methods based on thedescription herein.

Even though particular combinations of features are recited in theclaims and/or disclosed in the specification, these combinations are notintended to limit the disclosure of possible implementations. In fact,many of these features may be combined in ways not specifically recitedin the claims and/or disclosed in the specification. Although eachdependent claim listed below may directly depend on only one claim, thedisclosure of possible implementations includes each dependent claim incombination with every other claim in the claim set.

No element, act, or instruction used herein should be construed ascritical or essential unless explicitly described as such. Also, as usedherein, the articles “a” and “an” are intended to include one or moreitems, and may be used interchangeably with “one or more.” Furthermore,as used herein, the term “set” is intended to include one or more items,and may be used interchangeably with “one or more.” Where only one itemis intended, the term “one” or similar language is used. Also, as usedherein, the terms “has,” “have,” “having,” or the like are intended tobe open-ended terms. Further, the phrase “based on” is intended to mean“based, at least in part, on” unless explicitly stated otherwise.

What is claimed is:
 1. A method, comprising: receiving information thatspecifies a graphical scene, the graphical scene being associated with apolar coordinate system, data, to be plotted in the graphical scene,being plotted with regard to the polar coordinate system, and theinformation including a syntax of: polar[characters], where [characters]includes one or more characters and/or arguments, and the receivingbeing performed by a device; and generating a first structured pluralityof objects that comprise one or more objects storing properties thatdefine one or more elements of the graphical scene, the generating beingperformed by the device, and the first structured plurality of objectsbeing generated based on a second structured plurality of objects, thesecond structured plurality of objects storing properties that defineone or more elements of a graphical scene in a Cartesian coordinatesystem.
 2. The method of claim 1, where receiving the informationfurther comprises: receiving the information based on a polarapplication programming interface (API), the polar API being definedbased on a Cartesian API associated with the second structured pluralityof objects, the polar API including API instructions comprising a syntaxof Theta[characters] that correspond to API instructions of theCartesian API comprising a syntax of X[characters], and the polar APIincluding API instructions comprising a syntax of R[characters]corresponding to API instructions of the Cartesian API comprising asyntax of Y[characters].
 3. The method of claim 1, further comprising:receiving an instruction to modify a plotted element of the graphicalscene; determining a subset of the first structured plurality of objectsto which the instruction applies, the subset of the first structuredplurality of objects describing or relating to the element of thegraphical scene; and modifying the subset of the first structuredplurality of objects based on the instruction.
 4. The method of claim 3,where the element relates to at least one of: a range of the data to beplotted, an order in which to display labels of an axis of the graphicalscene, a numerical system in which to display labels of tick marks of anaxis of the graphical scene, one or more particular strings to use aslabels of an axis of the graphical scene, a scale based on which toconfigure an axis of the graphical scene, a location, of a theta-axis,at which to place a zero-value of the theta-axis, a location, in thegraphical scene, at which to place an r-axis, whether to place minortick marks in relation to an axis of the graphical scene, whether todetermine placement of tick marks in relation to an axis based on userinput or automatically, an orientation angle, relative to a defaultorientation angle, at which to orient labels of tick marks of an axis ofthe graphical scene, a color based on which to configure an axis of thegraphical scene, or a label for an axis of the graphical scene.
 5. Themethod of claim 4, where the instruction includes a syntax of at leastone of: [Theta/R]Lim, [Theta/R]Dir, [Theta/R]AxisUnits[Theta/R]TickLabels, [Theta/R]Scale, ThetaZeroLocation, RAxisLocation,[Theta/R]MinorTick, [Theta/R]Tick, [Theta/R]TickLabelRotation,[Theta/R]Color, or [Theta/R]Label, where [Theta/R] includes one or morecharacters indicating whether the instruction relates to an r-axis ofthe graphical scene or a theta-axis of the graphical scene, and wherethe instruction identifies the element to be modified.
 6. The method ofclaim 3, where the instruction indicates to concurrently plot multipledata sets in the graphical scene; and where the method furthercomprises: receiving a first data set; generating the graphical scene,including the first data set; receiving a second data set, the seconddata set being different than the first data set; and generating thegraphical scene, including the first data set and the second data set.7. The method of claim 6, where the instruction includes a syntax of oneor more of: hold on, or hold(‘on’).
 8. The method of claim 6, where theinstruction is a first instruction; and where receiving the first dataset comprises: receiving, before the first instruction, a secondinstruction that includes a syntax of: polarplot([data1]), where [data1]identifies the first data set; and where receiving the second data setcomprises: receiving, after the first instruction and the secondinstruction, a third instruction that includes a syntax of:plot([data2]), where [data2] identifies the second data set.
 9. Anon-transitory computer-readable medium storing instructions, theinstructions comprising: one or more instructions that, when executed byone or more processors, cause the one or more processors to: receiveinformation that specifies a graphical scene, the graphical sceneincluding a first coordinate axis, a second coordinate axis, and a thirdcoordinate axis, data, to be plotted in the graphical scene, beingplotted with regard to the first coordinate axis and the secondcoordinate axis, or with regard to the second coordinate axis and thethird coordinate axis, and the information including an instruction thatincludes a syntax of one or more of: yyaxis [arg], or yyaxis(‘[arg]’),where [arg], in the instruction, specifies the first coordinate axis orthe third coordinate axis; and generate a structured plurality ofobjects that comprise attributes that define one or more elements of thegraphical scene; receive an instruction to modify an element of thegraphical scene; and selectively modify the element of the graphicalscene with regard to the first coordinate axis or the third coordinateaxis based on a value of [arg].
 10. The non-transitory computer-readablemedium of claim 9, where the instruction pertains to at least one of: arange of data to be plotted, an order in which to display labels of anaxis of the graphical scene, a numerical system in which to displaylabels of tick marks of an axis of the graphical scene, one or moreparticular strings to use as labels of an axis of the graphical scene, ascale based on which to configure an axis of the graphical scene, alocation, in the graphical scene, at which to place an axis, whether toplace minor tick marks in relation to an axis of the graphical scene,whether to determine placement of tick marks in relation to an axisbased on user input or automatically, an orientation angle, relative toa default orientation angle, at which to orient labels of tick marks ofan axis of the graphical scene, a color based on which to configure anaxis of the graphical scene, or a label for an axis of the graphicalscene.
 11. The non-transitory computer-readable medium of claim 10,where the instruction includes a syntax at least one of: [X/Y/Z]Lim,[X/Y/Z]Dir, [X/Y/Z]AxisUnits, [X/Y/Z]TickLabels, [X/Y/Z]Scale,[X/Y/Z]AxisLocation, [X/Y/Z]MinorTick, [X/Y/Z]Tick,[X/Y/Z]TickLabelRotation, [X/Y/Z]Color, or [X/Y/Z] Label, where [X/Y/Z]includes one or more characters indicating whether the instructionrelates to an x-axis of the graphical scene, a y-axis of the graphicalscene, and/or a z-axis of the graphical scene, and where the instructionidentifies a value based on which to modify the element.
 12. Thenon-transitory computer-readable medium of claim 9, where the one ormore instructions, that cause the one or more processors to receive theinstruction, cause the one or more processors to receive the instructionvia a user interface; and where the one or more instructions, whenexecuted by the one or more processors, further cause the one or moreprocessors to: provide the graphical scene via the user interface. 13.The non-transitory computer-readable medium of claim 9, where the one ormore processors, when generating the plurality of objects, are to:generate the plurality of objects including a first dataspace object anda second dataspace object, the first dataspace object comprisingproperties that change attributes of objects, of the plurality ofobjects, that relate to the first coordinate axis or the secondcoordinate axis, and the second dataspace object comprising propertiesthat change attributes of objects, of the plurality of objects, thatrelate to the second coordinate axis or the third coordinate axis. 14.The non-transitory computer-readable medium of claim 13, where the oneor more instructions, that cause the one or more processors toselectively modify the element of the graphical scene, cause the one ormore processors to: render the graphical scene based on values of theattributes stored by the one or more objects and based on one or moreproperties of the first dataspace object or the second dataspace object,the one or more properties identifying information relating to themodified element of the graphical scene, and the one or more propertiesbeing modified based on the instruction to store information relating tothe modification to the graphical scene.
 15. A device, comprising: oneor more processors to: receive information that specifies a graphicalscene, the graphical scene including a coordinate axis, data, to beplotted in the graphical scene, being plotted with regard to thecoordinate axis; generate a structured plurality of objects, one or moreobjects, of the structured plurality of objects, storing properties thatdefine the graphical scene, a particular object, of the one or moreobjects, storing properties that define one or more elements of thecoordinate axis; receive an instruction identifying a modification to anelement of the coordinate axis, of the one or more elements of thecoordinate axis; and modify a property of the properties that define theone or more elements of the coordinate axis, based on the instruction,to implement the modification specified by the instruction.
 16. Thedevice of claim 15, where the instruction pertains to tick marks on thecoordinate axis, the instruction specifying at least one of: one or moretextual strings to display in relation to the tick marks, an exponentfor use in scaling values displayed in association with the tick marks,or a particular format for values displayed in association with the tickmarks.
 17. The device of claim 15, where the instruction includes asyntax of at least one of: MinorTickValues, TickLabelFormat, orExponent, and where the instruction includes a value based on which tomodify a property pertaining to markings on the coordinate axis.
 18. Thedevice of claim 15, where the instruction specifies a particularlocation in the graphical scene; and where the one or more processors,when modifying the property, are to: modify a property that defines aplacement of the coordinate axis to cause the coordinate axis to beplaced at the particular location.
 19. The device of claim 18, where theparticular location is an origin of a plot that is included in thegraphical scene.
 20. The device of claim 18, where the instructionincludes a syntax of: AxisLocation [arg], where [arg] specifies theparticular location.